Если использовать встроенный SQL плохо, как на практике отличается использование LINQ для выполнения запросов?

Question

Каков общий консенсус в отношении использования LINQ для выполнения запросов и манипуляций внутри строки и как это отличается от встраивания операторов SQL в ваш код (что считается нет, нет)?

Answer 1

Игнорирование всего не связанного с SQL использования LINQ и только рассмотрение LINQ-to-SQL.

LINQ-запросы - это объекты, которые сохраняют запрос определение , а эквивалентный SQL создается только в тот момент, когда запрос фактически повторяется. Это позволяет правильно разделять компоненты и разрешать обработку стиля конвейера , когда запросы возвращаются нижними уровнями (например, репозиториями) и преобразуются более высокими компонентами в стеке. Запрос может содержать новые фильтры, объединения и другие «артефакты» от каждого компонента в конвейере обработки, пока он не достигнет окончательной формы, которая в конечном итоге повторяется. Это манипулирование невозможно на практике с использованием простого текстового SQL.

Еще одним преимуществом LINQ является то, что его синтаксис легче понять для разработчиков, не связанных с базами данных. Экспертиза синтаксиса SQL на удивление труднодоступна. Немногие разработчики готовы потратить время на изучение тонкостей SQL, выходящих за рамки SELECT * FROM ... WHERE .... Синтаксис linq ближе к повседневной среде .Net и использует существующий набор навыков на этом уровне (например, лямбда-выражения), а не заставляет разработчика изучать правильный SQL для целевого внутреннего интерфейса (T-SQL, PL-SQL). так далее). Учитывая, что выражение linq выражает желаемый результат в прямой форме в реляционной алгебре, поставщикам гораздо проще создать соответствующий SQL (или даже сгенерировать прямой план выполнения!). Сравните это с невыполнимой задачей: «универсальным» драйверам баз данных пришлось столкнуться с текстом SQL. Кто-нибудь помнит escape-синтаксис ODBC?

Answer 2

Вы правы: «Внедрение оператора SQL в ваш код - это неплохо». Это ужасно.

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

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

Причина в том, что бизнес-логика принадлежит бизнес-уровню, а не уровню данных.

Конечно, если сгенерированный Linq to SQL окажется чем-то грязным и медленным, вы должны использовать процедуру.

Одним из больших преимуществ Linq To SQL является то, что вы можете объединять вместе фильтры - вы там, где предложение просто динамически добавляется через вашу логику по мере необходимости. Вам не нужно создавать новые процессы только потому, что вы хотите вызвать набор данных, основанный на нескольких параметрах.

Answer 3

Два преимущества "Linq To Sql" против (общий наихудший случай) "встроенный SQL" .

Параметры обрабатываются как параметры, а не как объединенный текст - это устраняет проблемы внедрения SQL.

Отдельный уровень модели позволяет во время компиляции проверять, что сгенерированный sql будет соответствовать схеме. (В худшем случае встроенного sql вы не сможете узнать во время компиляции, например, если бы вы ссылались на удаленный столбец)

Answer 4

Внедрение оператора SQL в ваш код - это неплохо. Все зависит от того, на каком уровне вашего приложения вы их пишете.

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

Answer 5

Много работали со встроенным SQL, реальная опасность заключается в том, что это технология генерации кода. Вы пишете код на C (или на любом другом языке), затем переключаетесь на SQL, затем снова на C. Позже, перед компиляцией, препроцессор переписывает код на все C. Результаты могут генерировать очень запутанные сообщения об ошибках. Вы вынуждены изучать API для взаимодействия с базой данных, от которой встроенный SQL должен был вас освободить. Наконец, вы рискуете внедрить бизнес-правила в свои запросы, путая бизнес-уровень и уровень данных. Linq избегает некоторых из этих проблем. Во-первых, Linq является частью языка. Конструкции работают более или менее так, как ожидает программист. Существует некоторый синтаксис типа SQL, но в основном синтаксис ориентирован на основной язык (т.е. C #). Проверки компиляции выполняются на самом коде, который вы написали. Поэтому нет необходимости переводить ошибки в синтаксис перед предварительной обработкой. Результатом запроса являются объекты и коллекции, как и следовало ожидать. Однако существует опасность смешивания бизнес-логики на уровне данных. Кроме того, у Linq есть свои проблемы с сообщениями об ошибках, когда рассматриваемое поле часто не включается. Тем не менее, это хороший компромисс между объектным миром и миром отношений.

Answer 6

В какой-то строке кода кто-то когда-нибудь решит, уместно ли вводить SQL. Но вместо этого вы будете использовать LINQ.

Так что не имеет значения, должен ли LINQ быть встроен, а SQL - нет. Вопрос в том, где вы хотите, чтобы ваше представление доступа к хранилищу данных было. Если вы пишете LINQ в какой-то строке кода, и вам не нравится, что эта область имеет доступ к хранимым данным, тогда это неправильное место.

LINQ - это просто абстракция для манипулирования данными. Это ярлык для фильтрации наборов. Так же, как базы данных понимают SQL, в среде .NET есть язык для общения с данными.

В чем разница между LINQ и операциями if в цикле, с данными, полученными из файла или с сетевого сокета? Нет, это просто синтаксис. Если вы SELECT * FROM table фильтруете каждую строку по функции, в чем разница с where c.SomeProperty < x с LINQ? Просто синтаксис.

Конечно, LINQ знает и делает больше, чем просто возвращает строки из базы данных. Он позволяет создавать экземпляры объектов из коллекции, но также = new ClassName(column1, colum2) из результатов операторов SQL.

Короче говоря, если где-то запись встроенного SQL в вашем коде - нет-нет, значит, он должен писать LINQ.

Но это зависит от проекта. Базы данных в основном понимают SQL, поэтому, по крайней мере, где-то в вашем коде, библиотеке или среде есть встроенные SQL.

Answer 7

Из моего небольшого понимания, используете ли вы LINQ-to-SQL или любой другой ORM или свой собственный код, который оборачивает вызовы SQL, это в основном дает вам абстракцию, благодаря которой вам не нужно беспокоиться о SQL.

Кроме того, если я прав - LINQ to SQL поддерживает только SQL Server.
Я думаю, что это позволяет вам строить свои критерии в SQL-стиле, используя синтаксис LINQ.

Лично я не знаю, почему кто-то использует LINQ to SQL.
Может ли эксперт помочь мне понять необходимость этого?

Answer 8

Глядя на другие ответы, возможно, я неправильно понял вопрос ... но я говорю о нормальном LINQ для коллекций в C #, а не LINQ-to-SQL:

Когда вы встраиваете в свой код операторы SQL (вместо того, чтобы делать их переменными или иным образом параметризировать свой SQL), вы значительно усложняете для себя, если хотите поддерживать другую базу данных в будущее. Несмотря на то, что SQL устарел и стандартизирован, существует множество несовместимостей между поставщиками.

В LINQ переносимость больше не является проблемой - ваш код написан на C #, а LINQ равен C #.

Answer 9

С одной стороны, операторы LINQ параметризованы - встроенные запросы не обязательно являются таковыми. С другой стороны, LINQ в основном создает слой ORM, позволяющий обрабатывать объекты базы данных по существу как объекты внутри кода, обеспечивая проверку времени компиляции. С другой стороны, встроенный запрос - это текстовый блок, который не сломается во время компиляции ...