Arka plan: Önümüzdeki ay boyunca, hakkında en azından hakkında LINQbağlamda üç görüşme yapacağım C#. İnsanların neyi anlamakta zorlandıklarına veya neyin yanlış bir izlenime sahip olabileceğine bağlı olarak hangi konuların adil bir şekilde dikkat edilmeye değer olduğunu bilmek istiyorum. Özellikle söz edilmeyecektir LINQiçin SQLhariç sorguları uzaktan (genellikle ve ifade ağaçları kullanarak çalıştırılabilir nasıl örnek olarak veya Varlık Framework IQueryable).

Peki, ne hakkında zor buldun LINQ? Yanlış anlamalar konusunda ne gördünüz? Örnekler aşağıdakilerden herhangi biri olabilir, ancak lütfen kendinizi sınırlamayın!

• C#Derleyici sorgu ifadelerini nasıl ele alır?
• Lambda ifadeleri
• İfade ağaçları
• Genişletme yöntemleri
• Anonim türler
• IQueryable
• Ertelenmiş ve derhal icra
• Akışa karşı arabelleğe alınmış yürütme (ör. OrderBy ertelendi, ancak arabelleğe alındı)
• Örtük olarak yazılan yerel değişkenler
• Karmaşık genel imzaları okuma (örneğin Enumerable.Join )

Gecikmeli yürütme

Ertelenmiş yürütme kavramının şimdiye kadar bana yenilmesi gerektiğini biliyorum, ancak bu örnek gerçekten pratik bir kavrayış elde etmeme yardımcı oldu:

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

Yukarıdaki kod aşağıdakileri döndürür:

Before add:
Bob
Alice
Trent

After add:
Bob
Alice
Trent
Mallory

Orada sadece daha fazla olduğunu LINQiçin SQLve özellikler daha adil bir daha vardır SQLdilde gömülü ayrıştırıcı.

Büyük O gösterimi . LINQ, ne yaptığınızı bilmiyorsanız, O (n ^ 4) algoritmalarını fark etmeden yazmayı inanılmaz derecede kolaylaştırır.

Bir Lambdaifadenin hem bir ifade ağacına hem de anonim bir temsilciye çözümlenebileceğini düşünüyorum , böylece aynı bildirim lambdaifadesini hem IEnumerable<T>uzantı yöntemlerine hem de uzantı yöntemlerine iletebilirsiniz IQueryable<T>.

Götürdü yolu gibi birçok LINQ uzantısı yöntemleri olduğunu fark için çok uzun Single(), SingleOrDefault()vb lambdas almak aşırı yüklenmeleri var.

Yapabilirsin :

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

ve bunu söylemeye gerek yok - bazı kötü eğiticiler beni alışkanlık haline getirdi

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

LINQ to SQL'de sürekli olarak insanların DataContext'i, nasıl kullanılabileceğini ve nasıl kullanılması gerektiğini anlamadığını görüyorum. Çok fazla kişi, ne olduğuna dair DataContext'i (kalıcı bir nesne değil, bir İş Birimi nesnesi) görmüyor.

Ben insanların her işlem için yeni bir zaman yapmak yerine bir DataContext / session it / etc singleton çalışıyoruz kez gördüm.

Ve sonra IQueryable değerlendirilmeden önce DataContext atılır, ancak bu, IQueryable'ı anlamayan insanlarla DataContext'ten daha çok bir propata sahiptir.

Çok fazla karışıklık gördüğüm diğer kavram ise Query Syntax ve Expression Syntax. Bu noktada en kolay olanı kullanacağım, genellikle İfade Sözdizimi'ne bağlı kalacağım. Birçok insan sonunda aynı şeyi üreteceklerini hala anlamıyorlar, Sorgu her şeyden önce İfadeye derlendi.

Bence LINQ yanlış anlaşılmış kısmı bir olmasıdır dil uzatma değil, bir veritabanı uzantısı veya yapı.

LINQçok daha fazla LINQ to SQL.

Artık çoğumuz LINQkoleksiyonlarda kullandığımıza , ASLA geri dönmeyeceğiz!

LINQ 2.0'da Generics ve 3.0'da Anonim Türlerden bu yana .NET'in en önemli tek özelliğidir.

Ve şimdi Lambda'ya sahibiz, paralel programlama için sabırsızlanıyorum!

Birisi için, ifade ağaçlarının ne olduğunu ve nedenini bilmem gerekip gerekmediğini bilmek istiyorum.

LINQ için oldukça yeniyim. İşte ilk denememde tökezlediğim şeyler

• Birden fazla sorguyu bir araya getirme
• Visual Studio'da LINQ sorgularında etkin hata ayıklama.

Farkındayım aslen olmadıkları şey LINQ sözdizimi olmasıydı gelmez gerektiren IEnumerable<T>veya IQueryable<T>işe, LINQ sadece desen eşleştirme ile ilgili.

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

İşte cevabı (hayır, değil mi o blog yazma Bart De Smet yaptı ve LINQ I ettik Found iyi blogcular biri).

Hala "let" komutuyla (ki bunun için bir kullanım bulamadım) ve SelectMany (ki kullandım, ama doğru yaptığımdan emin değilim) ile sorun yaşıyorum

Linq sağlayıcıları arasındaki soyutlamanın ne zaman sızdığını anlamak. Bazı şeyler nesneler üzerinde çalışır ancak SQL üzerinde çalışmaz (örneğin, .TakeWhile). Bazı yöntemler SQL'ye (ToUpper) çevrilebilirken, diğerleri kullanılamaz. Bazı teknikler, diğerlerinin SQL'de daha etkili olduğu nesnelerde daha etkilidir (farklı birleştirme yöntemleri).

Birkaç şey.

1. İnsanlar Linq SQL Linq olarak düşünüyor.
2. Bazı insanlar, bu performans sonuçlarını dikkate almadan tüm foreach / mantığı Linq sorgularıyla değiştirmeye başlayabileceklerini düşünüyor.

Tamam, talep nedeniyle, bazı İfade şeyler yazdım. Blogger ve LiveWriter'ın bunu biçimlendirmek için nasıl komplo kurduklarından% 100 memnun değilim, ama şimdilik yapacak ...

Her neyse, işte gidiyor ... Özellikle insanların daha fazla bilgi istediği alanlar varsa, herhangi bir geri bildirim almak isterim.

İşte , öyle ya da nefret ediyorum ...

Bazı hata mesajları, özellikle LINQ SQL için oldukça kafa karıştırıcı olabilir. sırıtış

Herkes gibi birkaç kez ertelenmiş infaz tarafından ısırıldım. Benim için en kafa karıştırıcı şey SQL Server Sorgu Sağlayıcısı ve ne yapabilirsiniz ve onunla yapamam olduğunu düşünüyorum.

Hala bazen boş olan bir ondalık / para sütununda bir Sum () yapamaman beni şaşırtıyor. DefaultIfEmpty () kullanmak işe yaramaz. :(

LINQ'da ele alınması gereken harika bir şey, performans açısından kendinizi nasıl başaracağınızdır. Örneğin, bir döngü koşulu olarak LINQ sayısını kullanmak gerçekten akıllı değildir.

IQueryable, her ikisini de kabul eder Expression<Func<T1, T2, T3, ...>>ve Func<T1, T2, T3, ...>2. durumda performans düşüşü hakkında bir ipucu vermeden.

İşte ne demek istediğimi gösteren kod örneğ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);
}

Yanlış anlaşılmış olarak nitelendirilip nitelenmediğini bilmiyorum - ama benim için sadece bilinmiyor.

DataLoadOptions ve belirli bir sorgu yaptığımda hangi tabloların birleştirildiğini nasıl kontrol edebildiğimi öğrenmek beni memnun etti.

Daha fazla bilgi için buraya bakın: MSDN: DataLoadOptions

LINQ en yanlış anlaşılmış (ya da anlaşılmaması gerekir?) Yönü IQueryable ve özel LINQ sağlayıcıları olduğunu söyleyebilirim .

Bir süredir LINQ kullanıyorum ve IEnumerable dünyasında tamamen rahatım ve LINQ ile ilgili çoğu sorunu çözebilirim.

Ama IQueryable, İfadeler ve özel linq sağlayıcıları hakkında incelemeye ve okumaya başladığımda başımı döndürdü. Oldukça karmaşık bir mantık görmek istiyorsanız, LINQ to SQL'in nasıl çalıştığına bakın.

Ben LINQ bu yönünü anlamak için sabırsızlanıyoruz ...

Çoğu insanın söylediği gibi, en yanlış anlaşılan kısmın LINQ'nun T-SQL için sadece bir yedek olduğunu varsaydığını düşünüyorum. Menajerim gördüğü TSQL gurusu olarak kendini bize projede LINQ kullanmak ve hatta böyle bir şeyi serbest bırakılması için MS nefret izin vermedi !!!

Bir sorgu yürütüldüğünde var neyi temsil eder?

O mi iQueryable, iSingleResult, iMultipleResultveya does it uygulanmasına göre değişir. Dinamik yazarak (C #) standart statik yazmaya karşı (olduğu gibi) bazı spekülasyonlar var.

Bir döngüyü iç içe yerleştirmenin ne kadar kolay olduğunu herkesin anladığını sanmıyorum.

Örneğin:

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

group by hala başımı döndürüyor.

Ertelenmiş yürütme ile ilgili herhangi bir karışıklık, basit bir LINQ tabanlı koddan geçerek ve izleme penceresinde oynayarak çözülebilir olmalıdır.

Derlenmiş Sorgular

Eğer edemez zincir aslında IQueryableonlar yöntem çağrıları, çünkü (iken hala ve başka bir şey ama SQL çevirilebilir!) O mindboggling ve DRY büyük bir ihlalini oluşturur edilir etrafında o işin neredeyse imkansız olduğunu söyledi. Benim IQueryablederlenmiş sorguları (sadece ağır senaryolar için derlenmiş sorgu var) yok, ama derlenmiş sorgularda onları kullanamazsınız ve bunun yerine tekrar düzenli sorgu sözdizimi yazmanız gerekir. Şimdi 2 yerde aynı alt sorguları yapıyorum, bir şey değiştiğinde her ikisini de güncellemeyi hatırlamalıyım vb. Bir kabus.

LINQ to SQL ile ilgili # 1 yanılgısı, etkili bir şekilde kullanabilmek için STILL SQL bilmek zorunda olduğunu düşünüyorum.

Linq to Sql ile ilgili bir başka yanlış anlaşılmış şey, hala çalışması için veritabanı güvenliğinizi saçma noktasına düşürmeniz gerektiğidir.

Üçüncü nokta, Linq to Sql'nin Dynamic sınıflarıyla birlikte kullanılması (yani, sınıf tanımının çalışma zamanında oluşturulduğu anlamına gelir) muazzam miktarda tam zamanında derlemeye neden olur. Bu kesinlikle performansı öldürebilir.

Yavaş yüklenme.

Belirtildiği gibi, tembel yükleme ve ertelenmiş yürütme

LINQ to Objects ve LINQ to XML (IEnumerable), LINQ'dan SQL'e nasıl farklıdır (IQueryable)

NASIL tüm katmanlarda LINQ ile veri erişim katmanı, İş Katmanı ve Sunum Katmanı inşa .... ve iyi bir örnektir için.

Çoğu insanın söylediği gibi, en yanlış anlaşılan kısmın LINQ'nun T-SQL için sadece bir yedek olduğunu varsaydığını düşünüyorum. Kendini bir TSQL gurusu olarak gören yöneticim, projemizde LINQ kullanmamıza izin vermeyecek ve hatta böyle bir şeyi serbest bırakmak için MS'den nefret edecek!

İşlemler (TransactionScope kullanmadan)