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

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

С LINQ переносимость уже не проблема - ваш код написан на С#, а LINQ - С#.

Ответ 7

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

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

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

Ответ 8

В какой-то строке кода кто-то, когда-нибудь, решит, нужно ли вводить 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.

Ответ 9

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