Лучший вариант для динамических запросов?

Question

Я работаю над переносом старого приложения с WebForms на MVC, и частью этого процесса является удаление существующего слоя данных, перемещение логики из хранимых процедур в код. Поскольку изначально я работал только с базовыми функциями C # SQL (System.Data.SqlClient), я использовал упрощенный псевдо-ORM ( PetaPoco ), который просто принимает инструкцию SQL в виде строки и выполняет ее. Построение динамических запросов будет работать примерно так же в SQL - множество условий, которые добавляют и удаляют дополнительный код (средний запрос имеет ~ 30 фильтров).

Итак, осмотревшись немного, я нашел несколько вариантов:

• Связка строк и условных выражений, которые добавляют биты запроса по мере необходимости. Действительно неприятно, особенно когда запросы становятся сложными, а не то, чем я хочу заниматься, если существует лучшее решение.
• Группа условных выражений, использующих L2E . Выглядит более элегантно, но я тестировал L2E, слишком раздутый, в целом был ужасный опыт. Могу ли я сделать то же самое в L2S? Если да, то собирается ли L2S остаться на ближайшие 5-10 лет?
• Используйте PredicateBuilder . Все еще смотрю на это, те же вопросы, касающиеся L2S.
• РЕДАКТИРОВАТЬ: Я также могу просто придерживаться существующей модели хранимых процедур, но я все равно должен переписать их, так что это не помешает, чтобы посмотреть на другие варианты, так как мне все еще придется выполнять работу ноги.

Есть ли другие варианты? Может ли кто-нибудь взвесить некоторый опыт работы с любым из упомянутых методов - главным образом, выбрал ли выбранный вами метод желание создать машину времени и убить себя за ее реализацию?

Answer 1

Я бы посмотрел на LLBLGen. Код, который он генерирует, довольно хорош и настраиваем. Они также предоставляют надежного поставщика linq, который может помочь с вашими запросами. Я использовал его для пары крупных проектов и был очень счастлив.

http://www.llblgen.com/

Answer 2

По моему мнению, ни L2S, ни L2E не могут генерировать эффективный код SQL, особенно когда речь идет о сложных запросах. Даже в некоторых относительно простых случаях генерация запросов с помощью любого из двух методов может привести к неэффективному коду SQL, вот пример: Почему это дополнительное объединение увеличивает количество запросов?

При этом, если вы используете SQL Server, лучше использовать L2S, поскольку L2E предназначен для обработки любой базы данных; Из-за чего L2E будет генерировать неэффективный код SQL. Также следует помнить, что ни L2S, ни L2E не будут использовать базу данных tempDB, то есть генерировать временные таблицы или переменные таблиц или CTE.

Я бы переписал хранимые процедуры, максимально оптимизировав их, и использовал бы L2S / L2E для простых запросов, которые генерировали бы один обход (как минимум) на сервере, а также убедитесь, что план выполнения, который использует SQL Server, является наиболее эффективным (т.е. использует индексы и т. д.).

Hasanain

Answer 3

Не совсем ответ, но слишком долго для комментария:

Я создал веб-приложение среднего размера с использованием метода «сцепления кусочков SQL» и в настоящее время выполняю аналогичную работу, но с использованием L2E.

Я обнаружил, что при некотором самоконтроле метод concatenate-pices-of-sql не так уж и плох. Конечно, используйте параметризованные запросы, не пытайтесь вставить пользовательский ввод непосредственно в SQL.

Я постепенно увеличивал понимание метода L2E. Это обеспечивает безопасность типов, хотя некоторые вещи нужно выполнять «задом наперед» по сравнению с тем, как вы можете это делать с SQL - например, WHERE X IN (...) конструкции. Но пока я не попал ни в какое, с чем не справится L2E.

Мне кажется, что подход L2E было бы немного проще поддерживать, если бы другие люди были сильно вовлечены.

Есть ли у вас реальные случаи использования, когда "раздувание" L2E является проблемой? Или это просто общее чувство недомогания, когда вы чувствуете, что фреймворк слишком много делает за кулисами?

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

Другая проблема заключается в том, какую БД вы используете, и насколько актуальны ее привязки L2E. Если вы используете SQL Server, то нет проблем. MySql может быть более облупленным. Кусочек привлекательности L2E проистекает из его приятной интеграции с VStudio и способности VStudio автоматически создавать модели объектов из вашей БД. Не уверен, насколько хороша поддержка бэкэндов не-MS DB.