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

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

, Как LINQ к Объектам и LINQ к XML (IEnumerable) отличаются от LINQ до SQL (IQueryable)

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

group by все еще заставляет мою голову кружиться.

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

Я довольно плохо знаком с LINQ. Вот вещи, которые я споткнулся в своей первой попытке

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

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

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

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

В LINQ к SQL я постоянно вижу людей, не понимающих DataContext, как это может использоваться и как это должно использоваться. Слишком много людей не видят DataContext для того, каково это, объект Единицы работы, не персистентный объект.

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

И затем там избавляется от DataContext, прежде чем IQueryable был оценен, но это - больше продвижения с людьми, не понимающими IQueryable, чем DataContext.

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

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

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

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

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

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

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

Несколько вещей.

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

Хорошо, должный потребовать, я описал часть материала Выражения. Я не на 100% доволен тем, как блоггер и LiveWriter тайно замыслили форматировать его, но это сделает на данный момент...

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

Здесь это , как он, или ненавидьте его...

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

Я не знаю, квалифицирует ли это, как неправильно понято - но для меня, просто неизвестный.

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

Посмотрите здесь для большего количества информации: MSDN: DataLoadOptions

Я сказал бы, что самое недооцененное (или который должен быть не понят?) аспект LINQ IQueryable и пользовательские поставщики LINQ .

я использовал LINQ некоторое время теперь, и абсолютно удобно в мире IEnumerable и может решить большинство проблем с LINQ.

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

я надеюсь понять тот аспект LINQ...

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

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

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

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

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

LINQ - единственная наиболее значимая особенность .NET со времен Generics в 2.0 и Anonymous Types в 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 () для десятичных чисел Столбец / money иногда бывает пустым. Использование DefaultIfEmpty () просто не сработает. : (

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

Тот факт, что вы не можете связать 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 за то, что выпустила такую ​​штуку !!!

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

, Который является более быстрым, встроенным Linq-to-Sql или Linq-to-Sql с помощью Tsql Sprocs

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

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

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