Где должны хранится запросы к БД?

Зависит от выбранной архитектуры.

Я весьма рекомендую прочитать книгу "Руководство Microsoft по проектированию архитектуры приложений, 2-е издание", там есть множество советов по проектированию каждого слоя. Ручаюсь - голова кругом пойдёт от многообразия архитектурных паттернов.

Если говорить про слой работы с базой. в современных приложениях чаще встречается вариант динамических запросов ("из кода"), а не хранимых процедур:

В прошлом хранимые процедуры обеспечивали лучшую производительность по сравнению с динамическими SQL-выражениями. Однако сегодня современные ядра СУБД практически уравняли производительность обработки хранимых процедур и динамических SQL-выражений (использующих параметризованные запросы). Основными факторами при принятии решения об использовании хранимых процедур являются абстракция, удобство обслуживания и среда выполнения.

Из своей практики могу сказать, что да, хранимки использую реже, только когда нужна экстраоптимизация.

Если интересует широта и разнообразие архитектурных подходов к построению слоя работы с базой данных - то вот первая часть таблички:

• Active Record (Активная запись). Включает объект доступа к данным в сущность предметной области.
• Data Mapper (Преобразователь данных). Реализует слой преобразования между объектами и структурой базы данных, используемый для перемещения данных из одной структуры в другую, обеспечивая при этом их независимость.
• Data Transfer Object (Объект передачи данных). Объект, в котором сохраняются данные, передаваемые между процессами, что обеспечивает сокращение необходимого числа вызовов методов.
• Domain Model (Модель предметной области). Набор бизнес-объектов, представляющих сущности предметной области и отношения между ними.
• Query Object (Объект запроса). Объект, представляющий запрос к базе данных.
• Repository (Хранилище). Представление источника данных в памяти, работающее с сущностями предметной области.
• Row Data Gateway (Шлюз записи данных). Объект, выступающий в роли шлюза к отдельной записи источника данных.
• Table Data Gateway (Шлюз таблицы данных). Объект, выступающий в роли шлюза к таблице или представлению источника данных и выполняющий сериализацию всех запросов на выбор, вставку, обновление и удаление.
• Table Module (Модуль таблицы). Единый компонент, реализующий бизнес-логику для всех строк таблицы или представления базы данных.

Узнали какие-то из знакомых подходов? А ведь после таблицы отсылки к книгам Фаулера и отдельная глава 15 ещё раз про базы данных.

Поэтому: в реальных приложениях может быть устроено по-разному. Не надо думать, что если вам тут посоветуют какой-то один подход, то он будет единственно верным.

Правильным с точки зрения масштабируемости и гибкости будет решение, которое не использует SQL напрямую. Лучше использовать ORM, например nhibernate или entity, реализовать модуль, инкапсулирующий логику взаимодействия с БД в виде отдельного класса(синглтон) и обращаться к нему оттуда, откуда потребуется по заранее определенному контракту, который нужно расширять по мере появления новых задач.

Обычно запросы записывают все со стороны базы, т.е. в процедурах. Но если необходимы именно запросы, то пишут обычно в коде.