Причина не использовать LINQ

Ответ 1

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

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

Ответ 2

Другие ответы подразумевали это, но здесь он явно:

Термин "LINQ" может относиться к общему набору технологий для L anguage IN тегированного Q uery. Эти технологии позволяют преобразовать LINQ Query в дерево выражений. Это дерево может быть выполнено позднее, с помощью "LINQ Provider".

Поставщик LINQ ищет дерево выражений и преобразует его в, например, в операторы SQL или в XML DOM, или через графику объектов. Эти поставщики имеют такие имена, как "LINQ to SQL", "LINQ to Entities", "LINQ to Objects" и т.д.

Могут быть причины не использовать конкретного поставщика.

Многие из отдельных поставщиков LINQ поставляются с дополнительными инструментами (некоторые скажут, "багаж" ). Этот инструмент помогает предоставить некоторые из наиболее распространенных "плюсов и минусов" в отношении LINQ.

В частности, LINQ to SQL обеспечивает прямое, одно к одному сопоставление с схемой базы данных. Каждый класс LINQ соответствует одной таблице базы данных. Если структура базы данных изменяется, то и код. Это можно смягчить, используя представления.

Я считаю, что LINQ to SQL ограничен Microsoft SQL Server. Кроме того, Microsoft заявила, что LINQ to SQL не будет приоритетной инвестицией в будущем.

LINQ to Entities является частью ADO.NET Entity Framework (EF). EF обеспечивает моделирование ваших объектов на более абстрактном, концептуальном уровне. Например, у вас может быть объект Person, который принимает данные из двух таблиц, имеющих сопоставление от одного к одному. Коду, обращающемуся к этому объекту, не нужно беспокоиться о том, как таблицы разбиваются в базе данных.

Я считаю, что LINQ to Entities предназначен для работы со многими поставщиками ADO.NET, а не только с SQL Server. Кроме того, именно здесь Microsoft заявляет, что будет вкладывать свои инвестиции в будущее.

В обоих случаях LINQ для "некоторой базы данных" почти всегда будет иметь место случай, когда опытный разработчик SQL и/или администратор баз данных могут писать более качественные запросы, чем будут созданы LINQ. Если производительность является основным требованием, я считаю, что LINQ to Entities может отображать хранимые процедуры в методы для сущностей.

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

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

Ответ 3

Да, есть причины. Я расскажу о некоторых трудностях, с которыми я столкнулся при использовании различных поставщиков LINQ для РСУБД.

LINQ отлично работает в большинстве случаев, но когда вы хотите создавать сложные запросы (например, в приложениях для отчетов), статически типизированный характер становится недостатком. Трудно, например, условно присоединить или условно GROUP BY, потому что тип результата изменяется, даже если в конце вы хотите проецировать те же поля. Это также трудно сделать ЛЕВЫЙ ПРИСОЕДИНЯЙТЕСЬ. Если вы действительно цените динамические запросы, тогда лучше использовать SQL и ESQL.

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

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

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

Ответ 4

Единственная причина в том, что если у вас очень критичное для производительности приложение, так как запросы LINQ to Objects обычно работают хуже, чем для циклов. Это изменится с .Net 4.0, когда вы сможете использовать функции параллельной обработки PLINQ.

Во всяком случае, если у вас есть такое критически важное приложение, вы, вероятно, не должны использовать управляемую среду. в 99% случаев LINQ сделает ваш код более читабельным и более элегантным. Отложенный механизм выполнения может даже принести вам некоторую производительность при правильных обстоятельствах.

Ответ 5

Ну, если вы хотите сделать шаг назад и работать в 2 раза больше своих проектов, вы не должны его использовать; -)

Я думаю, что нет никакой реальной причины НЕ использовать его. Вы быстрее, умнее, и вы можете делать меньше ошибок и иметь больше контроля, так как вы можете работать "datatyped"

Ответ 6

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

Ответ 7

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

Лично я просто отвечаю требованиям, у меня нет полномочий для принятия решения, но LINQ отлично подходит для моделирования и включает в себя множество удобных функций.

Ответ 8

Архитектура LINQ хороша, но некоторые могут предпочесть читать исходный код, который не использует синтаксис LINQ SQL. Поэтому, если вы строго придерживаетесь читаемости, вы можете не использовать этот синтаксис.

Ответ 9

Я столкнулся с некоторыми проблемами, с которыми мне пришлось работать. Например, в зависимости от того, как устанавливаются отношения с базой данных, вы можете обнаружить, что linq2sql отлично подходит для запросов, но исправляет проблему корректно. Это случилось со мной, и я сделал настройку двух наборов объектов linq. У первого были все отношения, в которых я нуждался, поэтому я мог использовать более простой синтаксис для запросов, но второй не содержал отношения для того, когда я хотел обновить, так как они мне тогда не нужны.

Производительность не должна быть причиной не использовать ее, потому что в целом это только проблема для определенных процессов. И это не так, как вам нужно использовать linq исключительно или вообще не использовать. Я думаю, что многие люди думают: "О, прямой sql быстрее, и есть некоторые вещи, которые мне нужно сделать, чтобы быть быстрыми, поэтому я не могу использовать linq". Это просто глупо. Используйте его там, где можете, и используйте прямой sql, где вы не можете.

Ответ 10

Что я могу понять из разных сообщений, так это то, что это зависит от требования

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

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

Ответ 11

не использовать LINQ, если вы имеете в виду LINQ как "LINQ to SQL", а ваш SQL Server имеет проблемы с производительностью при выполнении Adhoc Query Execution.

Ответ 12

Что касается меня - только одна причина не использовать LINQ. Это сторонний инструмент для улучшения этого продукта. Я предпочитаю - Devart LinqConnect, например.

Ответ 13

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

Производить код без LINQ - это создание читаемого кода. Но я всегда пользуюсь;)

Ответ 14

Да, безусловно, делает вещи более читабельными и лаконичными. Конечно, в течение 15 лет я использовал его в Visual FoxPro;)