Comments 20
Вы где вообще такие вопросы нашли?
Linq2Sql? Are you kidding me?
Ощущение, что автор сами придумал мифы — сам их и развеял.
Угу.
Особенно удивил пункт
>>Существует два способа записи LINQ запросов: лямбда синтаксис и синтаксис запросов.
Лябда-синтаксис, который на самом деле самые обычные Extension-методы, не является LINQ. Потому что LINQ — это именно встроенный язык запросов (который, если я ничего не путаю, потом транслирутся в набор Extension-методов)
Особенно удивил пункт
>>Существует два способа записи LINQ запросов: лямбда синтаксис и синтаксис запросов.
Лябда-синтаксис, который на самом деле самые обычные Extension-методы, не является LINQ. Потому что LINQ — это именно встроенный язык запросов (который, если я ничего не путаю, потом транслирутся в набор Extension-методов)
Вы не правы насчёт LINQ:
msdn.microsoft.com/en-us/library/bb397947.aspx
И query syntax и method syntax — это всё linq.
msdn.microsoft.com/en-us/library/bb397947.aspx
И query syntax и method syntax — это всё linq.
Какой смысл было переводить это (с учетом актуальности)? Хотя цель как я понимаю выделена в конце текста жирным шрифтом? :)
Однажды начав думать исключительно в терминах LINQ, ваши запросы будут иметь очень мало общего с их SQL-аналогами. Во многих случаях, они будут также значительно проще.Особенности SQL в голове держать всё равно надо. Так, в Linq2Objects Sum от пустой последовательности выбросит исключение, а в SQL вернёт NULL, по которому, например, плохо работает сортировка. Вот и рождаются конструкции вида
.OrderBy (x => ((uint?) _someQuery_.Sum(y => y.Value)) ?? 0)
не имеющие смысла в рамках C# (Resharper не понимает, их, например), но заставляющие запрос работать как надо.
from c in db.Customers select c???
НИКТО в здравом уме так не пишет, автору (Joseph Albahari) видимо посчастливилось работать с индусами.
Linq 2 SQL уже давно мертв.
НИКТО в здравом уме так не пишет, автору (Joseph Albahari) видимо посчастливилось работать с индусами.
Linq 2 SQL уже давно мертв.
Мне кажется такие мифы могли быть актуальны в первый год после выхода 3.5 фреймворка.
Даже немного использовав его в проектах и ознакомившись с 101 linq samples, таких предположений возникать не должно.
Даже немного использовав его в проектах и ознакомившись с 101 linq samples, таких предположений возникать не должно.
Бывают ситуации, в которых для LINQ запросов необходимо ключевое слово var. Это происходит при проекции в анонимный тип:
string[] people = new [] { «Tom», «Dick», «Harry» };
var filteredPeople = people.Select (p => new { Name = p, p.Length });
При желании можно написать
IEnumerable<object>.
Миф #10
Лучший способ использования LINQ to SQL- это инстанциировать единственный экземпляр класса DataContext в статическом свойстве и использовать этот общий экземпляр на протяжении всей жизни приложения.
Ещё один миф — попытка оптимизировать обращения к базе, сохраняя SqlConnection между вызовами. Дотнет использует пул подключений, поэтому такая оптимизация — себе же проблем на голову.
А можно про это где то поподробнее почитать?
Как полагается, в MSDN.
msdn.microsoft.com/en-us/library/8xx3tyca.aspx
msdn.microsoft.com/en-us/library/8xx3tyca.aspx
Когда вы создаете запрос к базе данных, ключевое слово join вовсе необязательно: операция соединения может быть заменена использованием нескольких from-ов и подзапросов.
Оптимизация есть для данного case'а? Или EF построит запрос с подзапросами. В таком случае от джоинов избавились, но получили падение производительности на подзапросах.
Sign up to leave a comment.
10 мифов о LINQ