Кто такие крупнейшие люди ошибки, делают, начиная использовать LINQ? [закрытый]

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

Это относится к Linq to SQL.

A фантастический инструмент для Linq - LinqPad от Joe Albahari, позволил мне изучить Linq намного быстрее. Если у вас его нет, получите! И я даже не в комиссии;)

Использование linq2sql для таблиц без первичных ключей (не определяя их в конструкторе).

Особенно, если они выполняют обновление, оно ничего не обновляет, и вы получаете без ошибок.

Многие думают, что LINQ - это «магический SQL», который они могут использовать в коде. Это похоже на SQL, но это совсем другое. Понимание того, что это различие и что он действительно делает , предотвратит много разочарований.

Я полностью согласен с Адамом Робинсоном, на самом деле БОЛЬШАЯ ошибка в том, что люди останавливаются на синтаксисе красоты, не углубляясь в технические факты, с точки зрения воздействий или архитектурных взглядов.

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

На самом деле, начиная с больших и растущих реализаций, нет полного списка лучших практик, лучшие практики могут начинаться с:

1. понимания до того, что тип реализации будет использоваться (Linq2Sql, Linq2Objects, Linq2CSV, Linq2Excel, Linq2LDAP, Linq2JSON,Linq2Xml, Linq2Xsd и т. Д.)
2. затем пытаемся понять, какие основные технологические возможности предназначены для выбранной реализации

LINQ as a language is pretty straight forward and not so unexpected, especially if you're familiar with functional programming.

The concept of Deferred Execution is probably the biggest gotcha, and one of the best features. When you use LINQ that returns an IQueryable it's important to remember you are NOT executing whatever code you just wrote. It isn't until you call one of the methods that produces some other result that the query is executed.

Also, in terms of the LINQ to SQL provider, the biggest gotcha I've found is the performance cost. Turns out there is significant CPU cost to constructing SQL queries that are incurred every time the LINQ query is ran, unless you pre-compile your highly trafficked queries.

Possibly, one of the misconceptions people might have is that the way a LINQ query is written, especially LINQ2SQL, has no impact on performance. One should always know what goes on in the background, if one intends to write code that has high performance, otherwise you might end up with interesting timeouts, OOMexceptions, stack overflow and such... =)

Что-то, что приходит на ум, это

• Это должно быть медленнее, лучше использовать простой C #
• Пытаться использовать его там, где простой C # будет более читабельным / управляемым

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

The biggest mistake people make when using LINQ is the same as when people try to use any sort of technology that lies on top of a technology that they don't have any good grounding in.

If you can't understand proper/efficient DB querying, you will screw up with LINQ.

If you can't understand the basic fundamentals of ADO.NET and data access, you'll probably screw up.

People think that by using LINQ it will allow them to coast by, but it won't.

That it only refers to LINQ to SQL

Не понимая различий между (или существованием!):

.First()
.FirstOrDefault()
.Single()
.SingleOrDefault()

Не понимает отложенное выполнение .

Here is one, LINQ to SQL queries involving strings cause SQL Server procedure cache bloat People need to be aware of that

Говоря за себя, важно знать, когда последовательность будет буферизована или передана в поток.

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