Bối cảnh: Trong tháng tới, tôi sẽ có ba bài nói về hoặc ít nhất là bao gồm LINQtrong bối cảnh C#. Tôi muốn biết những chủ đề nào đáng để chú ý một cách hợp lý, dựa trên những gì mọi người có thể cảm thấy khó hiểu hoặc những gì họ có thể có ấn tượng sai lầm. Tôi sẽ không nói cụ thể về LINQđến SQLhoặc khung Entity trừ khi được ví dụ về cách truy vấn có thể được thực hiện từ xa sử dụng cây biểu thức (và thường IQueryable).

Vì vậy, những gì bạn đã tìm thấy khó khăn về LINQ? Bạn đã thấy gì về sự hiểu lầm? Ví dụ có thể là bất kỳ điều nào sau đây, nhưng xin đừng giới hạn bản thân!

• Cách C#trình biên dịch xử lý các biểu thức truy vấn
• Biểu thức Lambda
• Cây biểu hiện
• Phương pháp mở rộng
• Các loại ẩn danh
• IQueryable
• Trì hoãn so với thực hiện ngay lập tức
• Truyền phát so với thực thi được đệm (ví dụ OrderBy bị hoãn nhưng được đệm)
• Hoàn toàn gõ các biến cục bộ
• Đọc chữ ký chung phức tạp (ví dụ Enumerable.Join )

Thi hành chậm trễ

Bây giờ tôi biết khái niệm thực thi bị trì hoãn nên được đánh vào tôi, nhưng ví dụ này thực sự đã giúp tôi nắm bắt thực tế về nó:

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);
    }
}

Đoạn mã trên trả về như sau:

Before add:
Bob
Alice
Trent

After add:
Bob
Alice
Trent
Mallory

Rằng có nhiều hơn là chỉ LINQđể SQLvà các tính năng có nhiều hơn chỉ là một SQLphân tích cú pháp nhúng bằng ngôn ngữ.

Ký hiệu O lớn . LINQ làm cho việc viết các thuật toán O (n ^ 4) cực kỳ dễ dàng mà không nhận ra nó, nếu bạn không biết bạn đang làm gì.

Tôi nghĩ rằng thực tế là một Lambdabiểu thức có thể phân giải cho cả cây biểu thức và đại biểu ẩn danh, vì vậy bạn có thể chuyển cùng một lambdabiểu thức khai báo cho cả IEnumerable<T>phương thức IQueryable<T>mở rộng và phương thức mở rộng.

Đã cho tôi cách quá lâu để nhận ra rằng nhiều phương pháp khuyến nông LINQ như Single(), SingleOrDefault()vv có quá tải mà mất lambdas.

Bạn có thể làm :

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

và không cần phải nói điều này - điều mà một số hướng dẫn tồi đã khiến tôi có thói quen làm

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

Trong LINQ to SQL tôi liên tục thấy mọi người không hiểu DataContext, làm thế nào nó có thể được sử dụng và làm thế nào để sử dụng nó. Quá nhiều người không nhìn thấy DataContext cho mục đích của nó, một đối tượng Đơn vị công việc, không phải là một đối tượng liên tục.

Tôi đã thấy nhiều lần mọi người đang cố gắng đơn lẻ một DataContext / phiên nó / vv thay vì tạo thời gian mới cho mỗi hoạt động.

Và sau đó, việc xử lý DataContext trước khi IQueryable được đánh giá nhưng đó là một điều khó hiểu với những người không hiểu IQueryable hơn DataContext.

Khái niệm khác mà tôi thấy rất nhiều nhầm lẫn với là Cú pháp Cú pháp vs Cú pháp Biểu thức. Tôi sẽ sử dụng cái nào là dễ nhất vào thời điểm đó, thường gắn bó với Expression Syntax. Nhiều người vẫn không nhận ra rằng cuối cùng họ sẽ tạo ra cùng một thứ, Truy vấn được biên dịch thành Biểu thức.

Tôi nghĩ phần bị hiểu lầm của LINQ là nó là một phần mở rộng ngôn ngữ , không phải là phần mở rộng hoặc xây dựng cơ sở dữ liệu.

LINQquá nhiều chi tiết hơn LINQ to SQL.

Bây giờ hầu hết chúng ta đã sử dụng LINQtrên các bộ sưu tập, chúng tôi sẽ KHÔNG BAO GIỜ quay trở lại!

LINQ là tính năng quan trọng nhất đối với .NET kể từ Generics trong 2.0 và Các loại ẩn danh trong 3.0.

Và bây giờ chúng ta có Lambda, tôi không thể chờ lập trình song song!

Tôi chắc chắn sẽ biết nếu tôi cần biết cây biểu hiện là gì và tại sao.

Tôi khá mới với LINQ. Đây là những điều tôi đã vấp ngã trong nỗ lực đầu tiên của tôi

• Kết hợp nhiều truy vấn thành một
• Gỡ lỗi hiệu quả các truy vấn LINQ trong Visual Studio.

Một cái gì đó mà ban đầu tôi không nhận ra là cú pháp LINQ không yêu cầu IEnumerable<T>hoặc IQueryable<T>không hoạt động, LINQ chỉ là về khớp mẫu.

văn bản thay thế http://bartdesmet.info/images_wlw/QIsIQueryabletheRightChoiceforMe_13478/image_thumb_3.png

Đây là câu trả lời (không, tôi đã không viết blog đó, Bart De Smet đã làm và anh ấy là một trong những blogger giỏi nhất trên LINQ tôi đã tìm thấy).

Tôi vẫn gặp sự cố với lệnh "let" (mà tôi chưa bao giờ tìm thấy cách sử dụng) và SelectMany (mà tôi đã sử dụng, nhưng tôi không chắc là mình đã làm đúng)

Hiểu khi sự trừu tượng giữa các nhà cung cấp Linq bị rò rỉ. Một số thứ hoạt động trên các đối tượng nhưng không phải SQL (ví dụ: .TakeWhile). Một số phương thức có thể được dịch sang SQL (ToUpper) trong khi các phương thức khác không thể. Một số kỹ thuật hiệu quả hơn trong các đối tượng trong đó các kỹ thuật khác hiệu quả hơn trong SQL (các phương thức nối khác nhau).

Đôi điều.

1. Mọi người nghĩ về Linq như Linq thành SQL.
2. Một số người nghĩ rằng họ có thể bắt đầu thay thế tất cả các foreach / logic bằng các truy vấn Linq mà không xem xét hàm ý hiệu suất này.

OK, do nhu cầu, tôi đã viết lên một số nội dung Biểu hiện. Tôi không hài lòng 100% với cách blogger và LiveWriter đã âm mưu định dạng nó, nhưng bây giờ nó sẽ làm ...

Dù sao, ở đây đi ... Tôi thích bất kỳ thông tin phản hồi, đặc biệt là nếu có những khu vực mà mọi người muốn biết thêm thông tin.

Nó đây , thích hay ghét nó ...

Một số thông báo lỗi, đặc biệt là từ LINQ đến SQL có thể khá khó hiểu. cười toe toét

Tôi đã bị cắn bởi vụ hành quyết bị trì hoãn một vài lần như mọi người khác. Tôi nghĩ điều khó hiểu nhất đối với tôi là Nhà cung cấp truy vấn SQL Server và những gì bạn có thể và không thể làm với nó.

Tôi vẫn còn ngạc nhiên bởi thực tế là bạn không thể thực hiện Tổng () trên cột thập phân / tiền đôi khi trống. Sử dụng Default IfEmpty () sẽ không hoạt động. :

Tôi nghĩ rằng một điều tuyệt vời để bao quát trong LINQ là làm thế nào bạn có thể gặp rắc rối về hiệu suất. Ví dụ, sử dụng số đếm của LINQ làm điều kiện vòng lặp thực sự, thực sự không thông minh.

Rằng IQueryable chấp nhận cả hai Expression<Func<T1, T2, T3, ...>>và Func<T1, T2, T3, ...>, mà không đưa ra gợi ý về sự suy giảm hiệu năng trong trường hợp thứ hai.

Đây là ví dụ mã, điều đó thể hiện điều tôi muốn nói:

[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);
}

Tôi không biết nếu nó đủ điều kiện là hiểu lầm - nhưng đối với tôi, đơn giản là không biết.

Tôi rất vui khi tìm hiểu về DataLoadOptions và cách tôi có thể kiểm soát bảng nào được tham gia khi tôi thực hiện một truy vấn cụ thể.

Xem ở đây để biết thêm: MSDN: DataLoadOptions

Tôi muốn nói khía cạnh bị hiểu sai nhất (hoặc không nên hiểu?) Của LINQ là các nhà cung cấp LINQ tùy chỉnh và IQueryable .

Tôi đã sử dụng LINQ được một thời gian và hoàn toàn thoải mái trong thế giới IEnumerable và có thể giải quyết hầu hết các vấn đề với LINQ.

Nhưng khi tôi bắt đầu xem và đọc về IQueryable, và Expressions và các nhà cung cấp linq tùy chỉnh, nó khiến đầu óc tôi quay cuồng. Hãy xem cách LINQ to SQL hoạt động nếu bạn muốn xem một số logic khá phức tạp.

Tôi mong được hiểu khía cạnh đó của LINQ ...

Như hầu hết mọi người đã nói, tôi nghĩ phần bị hiểu lầm nhất là giả định LINQ chỉ là sự thay thế cho T-SQL. Người quản lý của tôi, người tự coi mình là một chuyên gia TSQL sẽ không cho phép chúng tôi sử dụng LINQ trong dự án của mình và thậm chí ghét MS vì đã phát hành một thứ như vậy !!!

Var thể hiện điều gì khi một truy vấn được thực thi?

Được nó iQueryable, iSingleResult, iMultipleResult, hoặc dùng nó thay đổi dựa trên việc thực hiện. Có một số suy đoán về việc sử dụng (có vẻ là) gõ động so với gõ tĩnh tiêu chuẩn trong C #.

Làm thế nào dễ dàng để lồng một vòng lặp là điều tôi không nghĩ mọi người đều hiểu.

Ví dụ:

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

group by vẫn làm đầu óc tôi quay cuồng.

Bất kỳ sự nhầm lẫn nào về việc thực thi bị trì hoãn sẽ có thể được giải quyết bằng cách chuyển qua một số mã dựa trên LINQ đơn giản và chơi xung quanh trong cửa sổ xem.

Truy vấn tổng hợp

Thực tế là bạn không thể xâu chuỗi IQueryablevì chúng là các cuộc gọi phương thức (trong khi vẫn không có gì khác ngoài SQL có thể dịch được!) Và gần như không thể làm việc xung quanh nó đang gây chú ý và tạo ra một sự vi phạm lớn về DRY. Tôi cần tài IQueryablekhoản quảng cáo mà tôi không có các truy vấn đã biên dịch (tôi chỉ có các truy vấn được biên dịch cho các kịch bản nặng), nhưng trong các truy vấn đã biên dịch, tôi không thể sử dụng chúng và thay vào đó cần phải viết lại cú pháp truy vấn thông thường. Bây giờ tôi đang thực hiện các truy vấn con giống nhau ở 2 nơi, cần nhớ cập nhật cả hai nếu có gì đó thay đổi, v.v. Một cơn ác mộng.

Tôi nghĩ quan niệm sai lầm số 1 về LINQ to SQL là bạn VẪN PHẢI BIẾT SQL để sử dụng hiệu quả nó.

Một điều sai lầm khác về Linq đối với Sql là bạn vẫn phải hạ thấp bảo mật cơ sở dữ liệu của mình đến mức vô lý để làm cho nó hoạt động.

Điểm thứ ba là việc sử dụng Linq cho Sql cùng với các lớp Động (có nghĩa là định nghĩa lớp được tạo trong thời gian chạy) gây ra một số lượng rất lớn việc biên dịch đúng lúc. Mà hoàn toàn có thể giết chết hiệu suất.

Tải lười biếng.

Như đã đề cập, lười tải và thực thi hoãn lại

LINQ to Object và LINQ to XML (IEnumerable) khác nhau như thế nào từ LINQ đến SQL (IQueryable)

CÁCH xây dựng Lớp truy cập dữ liệu, Lớp nghiệp vụ và Lớp trình bày với LINQ trong tất cả các lớp .... và một ví dụ điển hình.

Như hầu hết mọi người đã nói, tôi nghĩ phần bị hiểu lầm nhất là giả định LINQ chỉ là sự thay thế cho T-SQL. Người quản lý của tôi, người tự coi mình là một chuyên gia TSQL sẽ không cho phép chúng tôi sử dụng LINQ trong dự án của mình và thậm chí ghét MS vì đã phát hành một thứ như vậy !!!

Giao dịch (không sử dụng TransactionScope)