Причина не использовать [закрытый] LINQ

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

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

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

LINQ отлично работает в большинстве случаев, но когда вы хотите создавать сложные запросы (например, в приложениях для создания отчетов), он статически- типизированный характер становится недостатком. Трудно, например, условно JOIN или условно GROUP BY, потому что тип результата меняется, даже если в конце вы хотите спроецировать те же поля. Также сложно сделать LEFT JOIN. Если вы действительно цените динамические запросы, тогда лучше использовать SQL и ESQL.

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

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

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

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

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

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

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

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

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

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

Поставщик 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 для таблиц базы данных. В этом случае используйте представления или хранимые процедуры.

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

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