10 мифов о LINQ

[hardex]

Вы где вообще такие вопросы нашли?

[lair]

Linq2Sql? Are you kidding me?

[raptor]

Ощущение, что автор сами придумал мифы — сам их и развеял.

[Zmops]

Угу.
Особенно удивил пункт

>>Существует два способа записи LINQ запросов: лямбда синтаксис и синтаксис запросов.

Лябда-синтаксис, который на самом деле самые обычные Extension-методы, не является LINQ. Потому что LINQ — это именно встроенный язык запросов (который, если я ничего не путаю, потом транслирутся в набор Extension-методов)

[Smerig]

Вы не правы насчёт LINQ:
msdn.microsoft.com/en-us/library/bb397947.aspx
И query syntax и method syntax — это всё linq.

[StealthDogg]

Какой смысл было переводить это (с учетом актуальности)? Хотя цель как я понимаю выделена в конце текста жирным шрифтом? :)

[kekekeks]

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

Особенности SQL в голове держать всё равно надо. Так, в Linq2Objects Sum от пустой последовательности выбросит исключение, а в SQL вернёт NULL, по которому, например, плохо работает сортировка. Вот и рождаются конструкции вида

.OrderBy (x => ((uint?) _someQuery_.Sum(y => y.Value)) ?? 0)

не имеющие смысла в рамках C# (Resharper не понимает, их, например), но заставляющие запрос работать как надо.

[Zmops]

>>Особенности SQL в голове держать всё равно надо

На самом деле надо держать в голове особенности не SQL, а работы текущего Linq провайдера. И понимать, что конструкция, работающая с Linq2Objects далеко не всегда будет работать с Linq2(Sql, WMI, EF, NHibernate, etc).

[novoselov]

from c in db.Customers select c???
НИКТО в здравом уме так не пишет, автору (Joseph Albahari) видимо посчастливилось работать с индусами.
Linq 2 SQL уже давно мертв.

[Danov]

> Linq 2 SQL уже давно мертв.

??????

[harlequin]

Мне кажется такие мифы могли быть актуальны в первый год после выхода 3.5 фреймворка.

Даже немного использовав его в проектах и ознакомившись с 101 linq samples, таких предположений возникать не должно.

[Fedorkov]

Бывают ситуации, в которых для LINQ запросов необходимо ключевое слово var. Это происходит при проекции в анонимный тип:

string[] people = new [] { «Tom», «Dick», «Harry» };
var filteredPeople = people.Select (p => new { Name = p, p.Length });

При желании можно написать IEnumerable<object>.

[Zmops]

и к какому типу потом эти object'ы приводить будете, чтобы получить доступ к полям?

[Nagg]

К dynamic, чо :-)

[Fedorkov]

Согласен, тут автор был прав.

[Fedorkov]

Миф #10

Лучший способ использования LINQ to SQL- это инстанциировать единственный экземпляр класса DataContext в статическом свойстве и использовать этот общий экземпляр на протяжении всей жизни приложения.

Ещё один миф — попытка оптимизировать обращения к базе, сохраняя SqlConnection между вызовами. Дотнет использует пул подключений, поэтому такая оптимизация — себе же проблем на голову.

[ishua]

А можно про это где то поподробнее почитать?

[Fedorkov]

Как полагается, в MSDN.
msdn.microsoft.com/en-us/library/8xx3tyca.aspx

[Mephistophele]

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

Оптимизация есть для данного case'а? Или EF построит запрос с подзапросами. В таком случае от джоинов избавились, но получили падение производительности на подзапросах.

[lair]

… это если сам SQL не сделает оптимизацию из подзапросов в join-ы (что он регулярно делает).