Где поставить sql при использовании dapper? - PullRequest
Новая
       30

Где поставить sql при использовании dapper?

20 голосов
/ 13 мая 2011

Я использую Dapper для проекта MVC3 на работе, и мне это нравится. Тем не менее, как вы должны наложить слой приложения при использовании dapper? В настоящее время я просто вставляю все свои sql непосредственно в контроллер ( slap ), но я думал о создании класса со статическими строками .. Так что я мог бы сделать 

var reports = Dapper.Query<Report>(conn, MySql.ReportsRunningQuery)

Как вы храните свой sql при использовании dapper?

Ответы [ 3 ]

23 голосов
/ 13 мая 2011

Я бы сказал поместить sql туда, где вы бы поместили эквивалентный запрос LINQ, или sql для DataContext.ExecuteQuery . Что касается того, где это ... ну, это зависит от вас и зависит от того, сколько разлуки вы хотите.

Однако лично я не вижу смысла скрывать SQL в отдельном классе от вызова Query<T> - вы хотите увидеть их в контексте, чтобы вы могли легко проверить данные (и, действительно, параметры). Вы также можете создавать запрос (все еще параметризованный) на месте. Но для обычного статического запроса я бы держал TSQL как литерал рядом с кодом, если только у меня нет веской причины для его абстрагирования, т.е. 

var reports = conn.Query<Report>(@"
select x.blah, y.blah
from x (snip)
where x.ParentId = @parentId and y.Region = @region", new {parentId, region});

(обратите внимание также на альтернативный метод расширения использование в приведенном выше)

IMO, ключ в вышесказанном заключается в том, что крайне маловероятно , что вы когда-либо повторно будете использовать этот запрос из из любого другого места - логика вместо этого будет помещен в метод, и этот метод вызывается из нескольких мест. Поэтому единственная другая причина, по которой вы можете скрыть запрос за центральной оболочкой, - это необходимость поддержки разных поставщиков баз данных (с разными диалектами SQL). И это реже, чем люди понимают.

6 голосов
/ 29 сентября 2013

Использование файла ресурсов действительно полезно для нас. Мы создаем файлы .sql в папке call / Sql и перетаскиваем их в раздел «Файлы» нашего объекта SqlResource. Раздел «Строки» файла ресурсов действительно чистый и простой для небольших фрагментов sql (например, функций, которые мы можем запрашивать).

Итак, наш sql выглядит так: 

var reports = conn.Query<Report>(SqlResource.Blahs_get, new {parentId, region});

Это обеспечивает чистоту репозиториев. И есть дополнительные преимущества наличия всех ваших sql в файле ресурсов, так как вы можете перебирать записи и потенциально запрашивать БД с помощью PARSEONLY, чтобы убедиться, что если объекты БД изменятся, ваши запросы прервутся (обратите внимание, что это в основном, но не 100% надежно).

Итак, в заключение, для нас файлы ресурсов поддерживают чистоту, но, по мнению Марка Гравелла, они не предназначены для повторного использования в производственном коде ... каждый оператор sql должен использоваться только одной точкой в ​​вашем приложении.

3 голосов
/ 01 декабря 2017

Хотя этот вопрос уже давно устарел, я хотел бы предложить дополнительно внешнее хранилище SQL. Visual Studio (минимум 2015+) имеет подсветку синтаксиса, а также небольшой отладчик и менеджер соединений для файлов * .sql. Файлы могут быть помечены как Embedded Resource s и полностью содержаться в сборке, но отдельно от вашего кода. Вы будете ненавидеть видеть бесцветный SQL, встроенный в строки без проверки синтаксиса.

Я применил этот шаблон во всех моих недавних проектах и ​​в сочетании с ORM, таким как Dapper , взаимодействие между C # и SQL становится очень минимальным. У меня есть проект с открытым исходным кодом, расширяющий Dapper, доступный на GitHub , который может предоставить примеры, а также NuGet Package . Он также включает в себя механизм замены строк в стиле усы , который полезен для создания шаблонов ваших скриптов для повторного использования или для вставки условий динамической фильтрации.

...