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

#c_sharp #sql #net

Да, я знаю, что запросы к БД должны хранится в отдельном слое.

Правильно ли запросы в этом слое писать прямо в коде или их обычно хранят в ресурсах?
    

Ответы

Ответ 1

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

Я весьма рекомендую прочитать книгу "Руководство 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 ещё раз про базы данных.

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


Ответ 2

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


Ответ 3

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