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

Я бы сказал поместите 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});

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

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

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

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

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

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

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

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

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