배경 : 다음 달에, 나는 적어도 LINQ에 관한 내용을 포함 해서 적어도 세 번의 연설을 할 것 입니다 C#. 사람들이 이해하기 어려울 수있는 부분 또는 잘못된 인상을 받았을 수있는 주제에 따라 어느 정도의 관심을 기울일 가치가 있는지 알고 싶습니다. 내가 특별히 얘기하지 않습니다 LINQ에 SQL제외 쿼리가 원격으로 (보통과 표현의 나무를 사용하여 실행 할 수있는 방법의 예로 또는 엔티티 프레임 워크 IQueryable).

그래서 무엇에 대해 열심히 찾았 LINQ습니까? 오해의 관점에서 무엇을 보았습니까? 예는 다음 중 하나 일 수 있지만 자신을 제한하지 마십시오!

• C#컴파일러가 쿼리 표현식을 처리 하는 방법
• 람다 식
• 표현 트리
• 확장 방법
• 익명 유형
• IQueryable
• 지연된 대 즉시 실행
• 스트리밍 vs 버퍼 실행 (예 : 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언어에 포함 된 파서.

큰 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 to SQL에서 나는 DataContext를 이해하지 못하는 사람들, 그것을 어떻게 사용할 수 있고 어떻게 사용해야 하는지를 끊임없이 봅니다. 너무 많은 사람들이 지속성 오브젝트가 아닌 작업 단위 오브젝트가 무엇인지 DataContext를 보지 못합니다.

사람들이 각 작업에 대해 새로운 시간을 만드는 대신 DataContext / 세션 / 세션 등을 싱글 톤하려고하는 많은 시간을 보았습니다.

그런 다음 IQueryable을 평가하기 전에 DataContext를 폐기하지만 사람들은 DataContext보다 IQueryable을 이해하지 못하는 경향이 있습니다.

내가 혼동하는 다른 개념은 Query Syntax vs Expression Syntax입니다. 그 시점에서 가장 쉬운 것을 사용하고 종종 Expression Syntax를 사용합니다. 많은 사람들이 여전히 똑같은 결과물을 만들어 낼 것이라는 것을 아직 모르고 있습니다. Query는 결국 Expression으로 컴파일됩니다.

내 생각 LINQ의 오해 부분이 그것이라는 것이다 언어 확장 이 아닌 데이터베이스 확장 또는 구조.

LINQ이상 LINQ to SQL입니다.

이제 대부분의 사람들이 LINQ컬렉션 을 사용 했으므로 다시는 돌아 가지 않을 것입니다!

LINQ 2.0의 Generics와 3.0의 Anonymous Types 이후 .NET에서 가장 중요한 단일 기능입니다.

그리고 이제 Lambda가 있으므로 병렬 프로그래밍을 기다릴 수 없습니다!

나는 표현 트리가 무엇인지, 왜 필요한지 알아야합니다.

LINQ를 처음 사용합니다. 첫 시도에서 우연히 만난 것이 여기 있습니다.

• 여러 쿼리를 하나로 결합
• Visual Studio에서 LINQ 쿼리를 효과적으로 디버깅합니다.

내가 실현 원래하지 않았다 무언가는 LINQ 구문이었다 하지 않습니다 필요 IEnumerable<T>또는 IQueryable<T>작업에 LINQ 그냥 패턴 매칭에 관한 것입니다.

대체 텍스트 http://bartdesmet.info/images_wlw/QIsIQueryabletheRightChoiceforMe_13478/image_thumb_3.png

여기에 답이 (아니, 내가 하지 않은 그 블로그를 작성, 바트 드 스멧는했다, 그는 LINQ 내가 한 FOUND에서 최고의 블로거 중 하나).

"let"명령 (사용한 적이없는) 및 SelectMany (사용한 적이 있지만 올바르게 수행했는지 확실하지 않음)에 여전히 문제가 있습니다.

Linq 공급자 간의 추상화가 언제 유출되는지 이해합니다. SQL에서는 작동하지 않지만 객체에서는 작동하는 것이 있습니다 (예 : .TakeWhile). 일부 메소드는 SQL (ToUpper)로 변환 될 수 있지만 다른 메소드는 그렇지 않습니다. 일부 기법은 다른 기법이 SQL (다른 조인 방법)에서보다 효과적인 개체에서 더 효율적입니다.

몇 가지.

1. Linq를 Linq to SQL로 생각하는 사람들.
2. 어떤 사람들은 이러한 성능 영향을 고려하지 않고 모든 foreach / logic을 Linq 쿼리로 교체 할 수 있다고 생각합니다.

좋아, 수요 때문에, 나는 표현 재료 중 일부를 작성했습니다. 블로거와 LiveWriter가 어떻게 형식을 정립했는지에 대해 100 % 만족 스럽지는 않지만 지금은 그렇게 할 것입니다 ...

어쨌든, 여기에 간다 ... 나는 특히 사람들이 더 많은 정보를 원하는 영역이 있다면 의견을 듣고 싶습니다.

여기가 맘에 들어요

LINQ에서 SQL 로의 일부 오류 메시지는 매우 혼란 스러울 수 있습니다. 이를 드러내고 웃다

나는 다른 사람들처럼 두 번이나 연기 된 처형에 물렸다. 가장 혼란스러운 부분은 SQL Server Query Provider와 함께 할 수 있고 할 수없는 일이라고 생각합니다.

때로는 비어있는 소수 / 돈 열에서 Sum ()을 수행 할 수 없다는 사실에 여전히 놀랐습니다. 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 to 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쿼리를 컴파일하지 않은 ad-hoc (필요한 시나리오에 대해서만 쿼리를 컴파일 했음)이 필요하지만 컴파일 된 쿼리에서는 사용할 수 없으며 대신 일반 쿼리 구문을 다시 작성해야합니다. 이제 두 곳에서 동일한 하위 쿼리를 수행하고 있으며 변경 사항이있는 경우 두 가지를 모두 업데이트해야합니다. 악몽.

LINQ to SQL에 대한 # 1 오해는 SQL을 효과적으로 사용하기 위해 여전히 알고 있어야한다는 것입니다.

Linq to Sql에 대해 잘못 이해 한 또 다른 사실은 데이터베이스 보안을 작동하기 위해 부실한 지점으로 데이터베이스 보안을 낮추어야한다는 것입니다.

세 번째 요점은 Linq to Sql을 동적 클래스와 함께 사용하면 (런타임에 클래스 정의가 생성됨을 의미) 엄청난 양의 JIT (Just-In-Time) 컴파일이 발생한다는 것입니다. 절대적으로 성능을 저하시킬 수 있습니다.

게으른 로딩.

언급 한 바와 같이 지연로드 및 지연된 실행

LINQ to Objects와 LINQ to XML (IEnumerable)이 LINQ to SQL (IQueryable)과 다른 점

모든 계층에서 LINQ를 사용하여 데이터 액세스 계층, 비즈니스 계층 및 프레젠테이션 계층을 구축하는 방법 과 좋은 예.

대부분의 사람들이 말했듯이, 가장 오해 된 부분은 LINQ가 T-SQL의 대체품이라고 가정합니다. 자신을 TSQL 전문가로 생각하는 관리자는 우리 프로젝트에서 LINQ를 사용하지 못하게하고 심지어 MS를 싫어하여 그러한 것을 발표했습니다!

트랜잭션 (TransactionScope를 사용하지 않고)