Ленивая загрузка.

Отсроченное исполнение

Что есть больше, чем просто LINQ - SQL, и функции - это больше, чем просто синтаксический анализатор SQL, встроенный в язык.

Я думаю, что тот факт, что выражение Lambda может разрешаться как в дерево выражений, так и в анонимный делегат, поэтому вы можете передать одно и то же декларативное выражение lambda как методам расширения IEnumerable<T>, так и методам расширения IQueryable<T>.

Я думаю, вам следует уделять больше внимания наиболее часто используемым функциям LINQ в деталях - лямбда-выражениям и анонимным типам, а не тратить время на «трудные для понимания» вещи, которые редко используются в реальных программах.

У меня все еще есть проблемы с командой "let" (которой я никогда не находил применения) и SelectMany (которую я использовал, но не уверен, что сделал это правильно)

В LINQ to SQL я постоянно вижу людей, не понимающих DataContext, как его можно использовать и как его следует использовать. Слишком много людей не видят DataContext таким, какой он есть - объектом Unit of Work, а не постоянным объектом.

Я видел много раз, когда люди пытались выделить DataContext / session it / etc вместо того, чтобы создавать новое время для каждой операции.

И затем следует избавиться от DataContext до того, как IQueryable будет оценен, но это больше касается людей, не понимающих IQueryable, чем DataContext.

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

Понимание того, когда происходит утечка абстракции между поставщиками Linq. Некоторые вещи работают с объектами, но не с SQL (например, .TakeWhile). Некоторые методы могут быть переведены в SQL (ToUpper), а другие - нет. Некоторые методы более эффективны в объектах, тогда как другие более эффективны в SQL (различные методы соединения).

Я, например, хотел бы знать, нужно ли мне знать, что такое деревья выражений и почему.

Я новичок в LINQ. Вот то, о чем я споткнулся с первой попытки

• Объединение нескольких запросов в один
• Эффективная отладка запросов LINQ в Visual Studio.

Хорошо, из-за спроса я написал кое-что из Expression. Я не на 100% доволен тем, как blogger и LiveWriter сговорились отформатировать его, но пока этого достаточно ...

В любом случае, начнем ... Я бы хотел получить обратную связь, особенно если есть области, где людям нужна дополнительная информация.

Вот, нравится это или нет ...

Пара вещей.

1. Люди думают о Linq как о Linq to SQL.
2. Некоторые люди думают, что они могут начать замену всей логики / foreach запросами Linq, не учитывая это влияние на производительность.

Что быстрее, встроенное Linq-to-Sql или Linq-to-Sql с использованием Tsql Sprocs

... и есть ли случаи, когда лучше использовать запросы на стороне сервера (Sproc) или на стороне клиента (встроенный Linq).

Что представляет var при выполнении запроса?

Это iQueryable, iSingleResult, iMultipleResult, или он меняется в зависимости от реализации. Есть некоторые предположения об использовании (что кажется) динамической типизации по сравнению со стандартной статической типизацией в C#.

Понимание синтаксиса «магия». Как синтаксис понимания переводится в вызовы методов и какие вызовы методов выбираются.

Как, например:

from a in b
from c in d
where a > c
select new { a, c }

переводится в вызовы методов.

group by до сих пор кружит голову.

Любую путаницу в отношении отсроченное исполнение можно разрешить путем пошагового выполнения некоторого простого кода на основе LINQ и игры в окне наблюдения.

Для LINQ2SQL: ознакомьтесь с некоторыми из сгенерированных SQL и напишите запросы LINQ, которые преобразуются в хороший (быстрый) SQL. Это часть более серьезной проблемы, связанной с пониманием того, как сбалансировать декларативный характер запросов LINQ с реализмом, необходимым для быстрого их выполнения в известной среде (SQL Server).

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

Первоначально я не осознавал, что синтаксис LINQ не требует для работы IEnumerable<T> или IQueryable<T>, а LINQ - это всего лишь сопоставление с образцом.

альтернативный текст http://bartdesmet.info/images_wlw/QIsIQueryabletheRightChoiceforMe_13478/image_thumb_3.png

Вот ответ (нет, я, не сделал, пишу этот блог, это сделал Барт Де Смет, и он один из лучших блоггеров по LINQ, которых я нашел).

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

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

Как уже упоминалось, отложенная загрузка и отложенное выполнение

Чем LINQ to Objects и LINQ to XML (IEnumerable) отличаются от LINQ to SQL (IQueryable)

КАК для создания уровня доступа к данным, бизнес-уровня и уровня представления с LINQ на всех уровнях ... и хороший пример.

Я не знаю, можно ли это считать неправильно понятым, но для меня это просто неизвестно.

Мне было приятно узнать о DataLoadOptions и о том, как я могу контролировать, какие таблицы объединяются, когда я делаю конкретный запрос.

Подробнее см. Здесь: MSDN: DataLoadOptions

Я думаю, что в LINQ стоит рассказать о том, как вы можете столкнуться с проблемами, связанными с производительностью. Например, использование счетчика LINQ в качестве условия цикла на самом деле неразумно.

Я бы сказал, что наиболее непонятым (или непонятным?) Аспектом LINQ являются IQueryable и настраиваемые поставщики LINQ.

Я уже некоторое время использую LINQ, чувствую себя комфортно в мире IEnumerable и могу решить большинство проблем с помощью LINQ.

Но когда я начал смотреть и читать об IQueryable, Expressions и пользовательских поставщиках linq, у меня закружилась голова. Посмотрите, как работает LINQ to SQL, если вы хотите увидеть довольно сложную логику.

Я с нетерпением жду понимания этого аспекта LINQ ...

Это, конечно, не самое сложное, это просто то, что нужно добавить в список:

ThenBy() extension method

Не глядя на его реализацию, я сначала озадачен тем, как это работает. Все прекрасно понимают, как поля сортировки, разделенные запятыми, работают в SQL, но на самом деле я скептически отношусь к тому, что ThenBy будет делать то, что я действительно хочу. Как он может «узнать», каким было предыдущее поле сортировки - похоже, это должно быть.

Я собираюсь исследовать это сейчас ...

Как говорило большинство людей, я думаю, что наиболее неправильно понимаемая часть - это предположение, что LINQ - это просто замена T-SQL. Мой менеджер, который сам был считает как гуру TSQL, не позволил нам использовать LINQ в нашем проекте и даже ненавидит MS за выпуск такой штуки !!!

Я думаю, что часть LINQ неправильно понятая в заключается в том, что это расширение языка, а не расширение или конструкция базы данных.

LINQ - это намного больше, чем LINQ to SQL.

Теперь, когда большинство из нас использовали LINQ в коллекциях, мы НИКОГДА не вернемся!

LINQ - единственная наиболее важная функция .NET со времен Generics в версии 2.0 и анонимных типов в версии 3.0.

А теперь, когда у нас есть Lambda, я не могу дождаться параллельного программирования!

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

static void Linq_Deferred_Execution_Demo()
{
    List<String> items = new List<string> { "Bob", "Alice", "Trent" };

    var results = from s in items select s;

    Console.WriteLine("Before add:");
    foreach (var result in results)
    {
        Console.WriteLine(result);
    }

    items.Add("Mallory");

    //
    //  Enumerating the results again will return the new item, even
    //  though we did not re-assign the Linq expression to it!
    //

    Console.WriteLine("\nAfter add:");
    foreach (var result in results)
    {
        Console.WriteLine(result);
    }
}

Приведенный выше код возвращает следующее:

Before add:
Bob
Alice
Trent

After add:
Bob
Alice
Trent
Mallory

Обозначение Big O. LINQ позволяет невероятно легко писать алгоритмы O (n ^ 4), даже не осознавая этого, если вы не знаете, что делаете.

Некоторые сообщения об ошибках, особенно от LINQ to SQL, могут сбивать с толку. ухмылка

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

Я все еще поражен тем фактом, что вы не можете выполнить Sum () для столбца десятичных чисел / денег, который иногда бывает пуст. Использование DefaultIfEmpty () просто не сработает. :(

Я уверен, что почти один знает: вы можете использовать встроенные if в запросе linq. Что-то вроде этого:

var result = from foo in bars where (
    ((foo.baz != null) ? foo.baz : false) &&
    foo.blah == "this")
    select foo;

Я полагаю, вы также можете вставлять лямбды, хотя я не пробовал.

Скомпилированные запросы

Тот факт, что вы не можете связать IQueryable, потому что они являются вызовами методов (в то время как по-прежнему не что иное, как переводимый SQL!) И что это практически невозможно обойти, это ошеломляет и создает огромное нарушение DRY. Мне нужны мои IQueryable для ad-hoc, в которых у меня нет скомпилированных запросов (я скомпилировал запросы только для тяжелых сценариев), но в скомпилированных запросах я не могу их использовать, и вместо этого мне нужно снова писать обычный синтаксис запросов. Теперь я делаю те же подзапросы в двух местах, нужно не забывать обновлять оба, если что-то изменится, и так далее. Кошмар.

Мне потребовалось слишком много времени для путь, чтобы понять, что многие методы расширения LINQ, такие как Single(), SingleOrDefault() и т. д., Имеют перегрузки, которые принимают лямбды.

Ты можешь сделать :

Single(x => x.id == id)

и не нужно этого говорить - что из-за плохого учебника я привык делать

Where(x => x.id == id).Single()

Я не думаю, что все понимают, насколько легко вложить петлю.

Например:

from outerloopitem in outerloopitems
from innerloopitem in outerloopitem.childitems
select outerloopitem, innerloopitem

Как говорило большинство людей, я думаю, что наиболее неправильно понимаемая часть - это предположение, что LINQ - это просто замена T-SQL. Мой менеджер, считающий себя гуру TSQL, не позволил бы нам использовать LINQ в нашем проекте и даже ненавидит MS за выпуск такой штуки !!!

Тот факт, что вы не можете связать IQueryable, потому что они являются вызовами методов (при этом ничего другого, кроме SQL-переводимого!), И что это практически невозможно обойти, ошеломляет и создает огромное нарушение DRY. Мне нужны мои IQueryable для ad-hoc, в которых у меня нет скомпилированных запросов (я скомпилировал запросы только для тяжелых сценариев), но в скомпилированных запросах я не могу их использовать, и вместо этого мне нужно снова писать регулярный синтаксис запросов. Теперь я делаю те же подзапросы в двух местах, нужно не забывать обновлять оба, если что-то изменится, и так далее. Кошмар.

Этот IQueryable принимает как Expression<Func<T1, T2, T3, ...>>, так и Func<T1, T2, T3, ...>, без каких-либо намеков на снижение производительности во втором случае.

Вот пример кода, который демонстрирует, что я имею в виду:

[TestMethod]
public void QueryComplexityTest()
{
    var users = _dataContext.Users;

    Func<User, bool>                funcSelector =       q => q.UserName.StartsWith("Test");
    Expression<Func<User, bool>>    expressionSelector = q => q.UserName.StartsWith("Test");

    // Returns IEnumerable, and do filtering of data on client-side
    IQueryable<User> func = users.Where(funcSelector).AsQueryable();
    // Returns IQuerible and do filtering of data on server side
    // SELECT ... FROM [dbo].[User] AS [t0] WHERE [t0].[user_name] LIKE @p0
    IQueryable<User> exp = users.Where(expressionSelector);
}

Транзакции (без использования TransactionScope)

Я думаю, что заблуждение №1 о LINQ to SQL состоит в том, что вам ВСЕГДА НЕОБХОДИМО ЗНАТЬ SQL, чтобы эффективно его использовать.

Еще одна неверно понимаемая вещь о Linq to Sql заключается в том, что вам все равно придется снизить безопасность базы данных до абсурда, чтобы она работала.

Третий момент заключается в том, что использование Linq to Sql вместе с динамическими классами (что означает, что определение класса создается во время выполнения) вызывает огромное количество своевременной компиляции. Что может полностью убить производительность.

Как LINQ to SQL переводит это!

Предположим, что у нас есть таблица с 3 полями; A, B и C (это целые числа, имя таблицы - "Таблица1").
Показываю так:
[A, B, C]

Теперь мы хотим получить такой результат:
[X = A, Y = B + C]

А у нас есть такой класс:

public class Temp
{
   public Temp(int x, int y)
   {
      this.X = x;
      this.Y = y;
   }

   public int X { get; private set; }
   public int Y { get; private set; }
}

Затем мы используем это так:

using (MyDataContext db = new MyDataContext())
{
   var result = db.Table1.Select(row => 
                   new Temp(row.A, row.B + row.C)).ToList();
}

Сгенерированный SQL-запрос:

SELECT [t0].[A] AS [x], [t0].[B] + [t0].[C] AS [y]
FROM [Table1] AS [t0]

Он переводит .ctor файла Temp. Он знает, что я хочу, чтобы "row.B + row.C" (даже больше ...) включил параметр "y" моего конструктора класса!

Эти переводы меня очень интересуют. Мне это нравится, и я думаю, что писать такие переводчики (LINQ to Something) немного сложно!

Конечно! Плохая новость: LINQ to Entities (4.0) не поддерживает конструкторы с параметрами. (Почему нет?)

Я считаю «Создание дерева выражений» сложной задачей. Есть много вещей, которые меня беспокоят по сравнению с тем, что вы можете сделать с LINQ, LINQ to SQL и ADO.Net в целом.

Объясните, почему Linq не обрабатывает левое внешнее соединение так же просто, как в синтаксисе sql. Смотрите эти статьи: Реализация левого соединения с LINQ, Практическое руководство. Выполнение левых внешних соединений (Руководство по программированию на C#) Я был так разочарован, когда наткнулся на это препятствие, что все мое уважение к языку исчезло, и я решил, что это просто то, что быстро исчезнет. Ни один серьезный человек не захочет работать с синтаксисом, в котором отсутствуют эти проверенные на поле боя примитивы. Если бы вы могли объяснить, почему такого рода операции с наборами не поддерживаются. Я стал бы лучше и более открытым человеком.

Мне было трудно найти четкую информацию об анонимных типах, особенно в отношении производительности в веб-приложении. Также я бы предложил лучшие и практичные примеры Lamda-выражений и раздел «Как сделать» в темах, связанных с запросами и производительностью.

Надеюсь, мой краткий список поможет!