Передумови: Протягом наступного місяця я проведу три бесіди про або принаймні включення LINQу контекст C#. Мені хотілося б знати, на які теми варто приділяти неабияку увагу, виходячи з того, що людям може бути важко зрозуміти або на що вони можуть мати помилкове враження. Я не буду конкретно говорити про те, LINQщоб SQLабо в Entity Framework , за винятком прикладів того , як запити можуть бути виконані віддалено з допомогою дерев виразів (і зазвичай IQueryable).

Отже, що вам важко було LINQ? Що ви бачили з точки зору непорозумінь? Приклади можуть бути будь-якими з наведених нижче, але будь ласка, не обмежуйте себе!

• Як C#компілятор обробляє вирази запитів
• Лямбда-вирази
• Вираження дерев
• Методи розширення
• Анонімні типи
• IQueryable
• Відкладено проти негайного виконання
• Потокове та буферне виконання (наприклад, OrderBy відкладений, але буферний)
• Логічні змінні, що невдало вводять
• Читання складних загальних підписів (наприклад, Enumerable.Join )

Затримка виконання

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

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

Тобто більше , ніж просто , LINQщоб SQLі особливості більше , ніж просто SQLсинтаксичний аналізатор , вбудований в мові.

Big O нотації . LINQ дозволяє неймовірно легко писати алгоритми O (n ^ 4), не усвідомлюючи цього, якщо ви не знаєте, що робите.

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

Взяв мене шлях занадто довго , щоб зрозуміти , що багато методів розширення LINQ , такі як Single(), і SingleOrDefault()т.д. мають перевантаження , які приймають лямбда.

Ви можете зробити :

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

і не потрібно цього говорити - що якийсь поганий підручник отримав мене за звичку робити

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

У LINQ до SQL я постійно бачу людей, які не розуміють DataContext, як ним можна користуватися та як його використовувати. Забагато людей не бачать DataContext для того, що це таке, об'єкт "Unit of Work", а не постійний об'єкт.

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

А потім є розпорядження DataContext до того, як IQueryable буде оцінено, але це більше прихильність до людей, які не розуміють IQueyable, ніж DataContext.

Інша концепція, з якою я бачу велику плутанину, - це синтаксис запитів проти синтаксису виразів. Я використовую те, що коли-небудь найпростіше на той момент, часто дотримуючись синтаксис виразів. Дуже багато людей досі не усвідомлюють, що вони зроблять те саме, врешті-решт, Запит запитується в Expression.

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

LINQце набагато більше, ніж LINQ to SQL.

Тепер, коли більшість з нас використовували LINQколекції, ми НІКОЛИ не повернемося!

LINQ є найбільш важливою особливістю для .NET з часу Generics в 2.0, а Anonymous Types в 3.0.

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

Я напевно хотів би знати, чи потрібно мені знати, що таке дерева виразів і чому.

Я досить новачок у LINQ. Ось речі, на які я натрапив у першій спробі

• Поєднання декількох запитів в один
• Ефективно налагодження LINQ-запитів у Visual Studio.

Те, що я спочатку не усвідомлював, - це те, що синтаксис LINQ не вимагає IEnumerable<T>або IQueryable<T>не працює, LINQ - це лише відповідність шаблону.

alt text http://bartdesmet.info/images_wlw/QIsIQueryabletheRightChoiceforMe_13478/image_thumb_3.png

Ось відповідь (ні, я не писав цього блогу, Барт Де Смет зробив, і він один з найкращих блогерів на LINQ, який я знайшов).

У мене все ще виникають проблеми з командою «дозволити» (яку я ніколи не знаходив для використання) та SelectMany (яку я використав, але я не впевнений, що зробив це правильно)

Розуміння, коли абстракція серед постачальників Linq протікає. Деякі речі працюють на об'єктах, але не на SQL (наприклад, .TakeWhile). Деякі методи можуть бути переведені в SQL (ToUpper), а інші не можуть. Деякі методи ефективніші в об'єктах, де інші ефективніші в SQL (різні методи з'єднання).

Пару речей.

1. Люди думають про Linq як Linq для SQL.
2. Деякі люди думають, що вони можуть почати замінювати всі foreach / логіки запитами Linq, не враховуючи наслідків цієї продуктивності.

Гаразд, через попит, я написав деякі матеріали з Expression. Я не на 100% задоволений тим, як блогер і LiveWriter змовились його форматувати, але це робитиму зараз ...

Так чи інакше, я хотів би отримати будь-який відгук, особливо якщо є області, де люди хочуть отримати більше інформації.

Ось це , подобається або ненавидить ...

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

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

Я все ще вражений тим, що ви не можете зробити суму () на десятковій / грошовій колонці, яка іноді порожня. Використання DefaultIfEmpty () просто не працюватиме. :(

Я думаю, що чудова річ в LINQ полягає в тому, як ви можете потрапити в проблеми у виконанні проблем. Наприклад, використання рахунку LINQ як умови циклу є насправді, справді не розумним.

Цей 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);
}

Я не знаю, чи вважають це неправильно зрозумілим - але для мене просто невідомим.

Мені було приємно дізнатися про DataLoadOptions та як я можу контролювати, до яких таблиць приєднується, коли я роблю конкретний запит.

Дивіться тут для отримання додаткової інформації: MSDN: DataLoadOptions

Я б сказав, що найбільш неправильно зрозумілим (чи слід це не зрозуміти?) Аспектом LINQ є IQueryable та користувальницькі постачальники LINQ .

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

Але коли я почав роздивлятися і читати про IQueryable, і Expressions та власні провайдери linq, це змусило мене крутити голову. Погляньте, як працює LINQ до SQL, якщо ви хочете побачити досить складну логіку.

Я з нетерпінням чекаю розуміння цього аспекту LINQ ...

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

Що означає var, коли виконується запит?

Є чи це iQueryable, iSingleResult, iMultipleResultабо робить це змінюється в залежності від реалізації. Існує певна спекуляція щодо використання (як видається) динамічного набору тексту та стандартного статичного набору тексту в C #.

Як легко вкласти петлю - це те, що я не думаю, що всі розуміють.

Наприклад:

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

group by все ще змушує мою голову крутитися.

Будь-яку плутанину щодо відкладеного виконання слід вирішити, перейшовши через простий код на основі LINQ і погравши у вікно годинника.

Складені запити

Той факт, що ви не можете ланцюжок, IQueryableтому що це виклики методів (в той час як все ще нічого, крім SQL-перекладної!), І що майже неможливо обійти це, є розумним глухою і створює величезне порушення DRY. Мені потрібні мої IQueryableрекламні матеріали для спеціальних запитів, у яких я не збираю запити (я складаю лише запити для важких сценаріїв), але в складених запитах я не можу їх використовувати і замість цього потрібно знову писати синтаксис регулярних запитів. Зараз я роблю ті самі підзапити в 2-х місцях, потрібно пам’ятати, щоб оновити і те, якщо щось зміниться, і так далі. Кошмар.

Я думаю, що помилковим уявленням №1 щодо LINQ для SQL є те, що ВИ ВЖЕ ЗНАЄТЕ ЗНАТИ SQL, щоб ефективно використовувати його.

Ще одна неправильно зрозуміла річ щодо Linq - Sql - це те, що вам все одно доведеться знизити безпеку бази даних до абсурду, щоб змусити її працювати.

Третій момент полягає в тому, що використання Linq до Sql разом з класами Dynamic (тобто визначення класу створюється під час виконання) викликає величезну кількість щойно складеного часу компіляції. Що може абсолютно вбити продуктивність.

Ледаче завантаження.

Як згадувалося, ліниве завантаження і відкладене виконання

Наскільки LINQ для об'єктів і LINQ до XML (IEnumerable) відрізняються від LINQ до SQL (IQueryable)

ЯК створити рівень доступу до даних, бізнес-шар та шар презентацій за допомогою LINQ у всіх шарах .... і хороший приклад.

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

Операції (без використання TransactionScope)