Contexte: Au cours du mois prochain, je donnerai trois conférences sur ou du moins LINQdans le contexte de C#. J'aimerais savoir quels sujets méritent une attention particulière en fonction de ce que les gens peuvent avoir du mal à comprendre ou de ce qu'ils peuvent avoir une impression erronée. Je ne parlerai pas spécifiquement LINQde SQLou de l'Entity Framework, sauf en tant qu'exemples de la façon dont les requêtes peuvent être exécutées à distance à l'aide d'arbres d'expression (et généralement IQueryable).

Alors, qu'est-ce que vous avez trouvé difficile LINQ? Qu'avez-vous vu en termes de malentendus? Les exemples peuvent être les suivants, mais ne vous limitez pas!

• Comment le C#compilateur traite les expressions de requête
• Expressions lambda
• Arbres d'expression
• Méthodes d'extension
• Types anonymes
• IQueryable
• Exécution différée vs exécution immédiate
• Streaming vs exécution tamponnée (par exemple OrderBy est différé mais tamponné)
• Variables locales implicitement typées
• Lecture de signatures génériques complexes (par exemple Enumerable.Join )

Exécution retardée

Je sais que le concept d'exécution différée devrait maintenant me frapper, mais cet exemple m'a vraiment aidé à le comprendre concrètement:

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

Le code ci-dessus renvoie les éléments suivants:

Before add:
Bob
Alice
Trent

After add:
Bob
Alice
Trent
Mallory

Qu'il y ait plus que LINQpour SQLet les caractéristiques sont plus qu'un simple SQLanalyseur intégré dans la langue.

Notation Big O . LINQ facilite incroyablement l'écriture d'algorithmes O (n ^ 4) sans s'en rendre compte, si vous ne savez pas ce que vous faites.

Je pense que le fait qu'une Lambdaexpression peut se résoudre à la fois à une arborescence d'expression et à un délégué anonyme, vous pouvez donc transmettre la même lambdaexpression déclarative aux IEnumerable<T>méthodes d' IQueryable<T>extension et aux méthodes d'extension.

Ça m'a pris façon trop longtemps pour se rendre compte que de nombreuses méthodes d'extension LINQ tels que Single(), SingleOrDefault()etc ont lambdas qui prennent les surcharges.

Tu peux faire :

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

et je n'ai pas besoin de le dire - ce qu'un mauvais tutoriel m'a donné l'habitude de faire

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

Dans LINQ to SQL, je vois constamment des gens qui ne comprennent pas le DataContext, comment il peut être utilisé et comment il doit être utilisé. Trop de gens ne voient pas le DataContext pour ce qu'il est, un objet Unité de travail, pas un objet persistant.

J'ai vu de nombreuses fois où les gens essaient de singleton un DataContext / session it / etc plutôt que de faire un nouveau temps pour chaque opération.

Et puis il y a l'élimination du DataContext avant que le IQueryable n'ait été évalué, mais c'est plus un avantage pour les gens qui ne comprennent pas IQueryable que le DataContext.

L'autre concept avec lequel je vois beaucoup de confusion est la syntaxe de requête vs la syntaxe d'expression. J'utiliserai celle qui est la plus simple à ce stade, en utilisant souvent la syntaxe d'expression. Beaucoup de gens ne réalisent toujours pas qu'ils produiront la même chose à la fin, Query est compilé dans Expression après tout.

Je pense que la partie mal comprise de LINQ est qu'il s'agit d'une extension de langue , et non d'une extension ou d'une construction de base de données.

LINQest tellement plus que LINQ to SQL.

Maintenant que la plupart d'entre nous ont utilisé des LINQcollections, nous n'y retournerons JAMAIS!

LINQ est la fonctionnalité la plus importante de .NET depuis les génériques en 2.0 et les types anonymes en 3.0.

Et maintenant que nous avons Lambda, je ne peux pas attendre la programmation parallèle!

Pour ma part, j'aimerais savoir si j'ai besoin de savoir ce que sont les arbres d'expression et pourquoi.

Je suis assez nouveau sur LINQ. Voici les choses sur lesquelles je suis tombé lors de ma première tentative

• Combiner plusieurs requêtes en une seule
• Débogage efficace des requêtes LINQ dans Visual Studio.

Quelque chose que je n'avais pas réalisé à l'origine, c'est que la syntaxe LINQ ne nécessite pasIEnumerable<T> ou ne fonctionne pasIQueryable<T> , LINQ concerne simplement la correspondance de modèles.

texte alternatif http://bartdesmet.info/images_wlw/QIsIQueryabletheRightChoiceforMe_13478/image_thumb_3.png

Voici la réponse (non, je n'ai pas écrit ce blog, Bart De Smet l'a fait, et c'est l'un des meilleurs blogueurs sur LINQ que j'ai trouvé).

J'ai toujours des problèmes avec la commande "let" (pour laquelle je n'ai jamais trouvé d'utilisation) et SelectMany (que j'ai utilisé, mais je ne suis pas sûr de l'avoir fait correctement)

Comprendre quand l'abstraction entre les fournisseurs Linq fuit. Certaines choses fonctionnent sur des objets mais pas sur SQL (par exemple, .TakeWhile). Certaines méthodes peuvent être traduites en SQL (ToUpper) tandis que d'autres ne le peuvent pas. Certaines techniques sont plus efficaces dans les objets où d'autres sont plus efficaces dans SQL (différentes méthodes de jointure).

Quelques choses.

1. Les gens pensent que Linq est Linq to SQL.
2. Certaines personnes pensent qu'elles peuvent commencer à remplacer toutes les foreach / logic par des requêtes Linq sans tenir compte de ces implications en termes de performances.

OK, en raison de la demande, j'ai écrit quelques trucs sur l'expression. Je ne suis pas 100% satisfait de la façon dont le blogueur et LiveWriter ont conspiré pour le formater, mais cela suffira pour l'instant ...

Quoi qu'il en soit, voici ... J'adorerais tout commentaire, surtout s'il y a des domaines où les gens veulent plus d'informations.

Ça y est , on aime ou on déteste ...

Certains des messages d'erreur, en particulier de LINQ à SQL, peuvent être assez déroutants. sourire

J'ai été mordu par l'exécution différée à quelques reprises comme tout le monde. Je pense que la chose la plus déroutante pour moi a été le fournisseur de requêtes SQL Server et ce que vous pouvez et ne pouvez pas faire avec.

Je suis toujours étonné par le fait que vous ne pouvez pas faire un Sum () sur une colonne décimale / monétaire qui est parfois vide. L'utilisation de DefaultIfEmpty () ne fonctionnera tout simplement pas. :(

Je pense qu'une grande chose à couvrir dans LINQ est de savoir comment vous pouvez avoir des ennuis en termes de performances. Par exemple, utiliser le décompte de LINQ comme condition de boucle n'est vraiment, vraiment pas intelligent.

Que IQueryable accepte les deux, Expression<Func<T1, T2, T3, ...>>et Func<T1, T2, T3, ...>sans donner un indice sur la dégradation des performances dans le deuxième cas.

Voici un exemple de code, qui montre ce que je veux dire:

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

Je ne sais pas si cela peut être mal compris - mais pour moi, tout simplement inconnu.

J'ai été ravi d'en savoir plus sur DataLoadOptions et sur la façon dont je peux contrôler les tables jointes lorsque je fais une requête particulière.

Voir ici pour plus d'informations: MSDN: DataLoadOptions

Je dirais que l'aspect le plus mal compris (ou cela ne devrait-il pas être compris?) De LINQ est IQueryable et les fournisseurs LINQ personnalisés .

J'utilise LINQ depuis un certain temps maintenant et je suis parfaitement à l'aise dans le monde IEnumerable et je peux résoudre la plupart des problèmes avec LINQ.

Mais quand j'ai commencé à regarder et à lire sur IQueryable, et les expressions et les fournisseurs de linq personnalisés, cela m'a fait tourner la tête. Jetez un œil au fonctionnement de LINQ to SQL si vous voulez voir une logique assez complexe.

J'ai hâte de comprendre cet aspect de LINQ ...

Comme la plupart des gens l'ont dit, je pense que la partie la plus mal comprise est de supposer que LINQ est juste un remplacement pour T-SQL. Mon manager qui se considère comme un gourou de TSQL ne nous laisserait pas utiliser LINQ dans notre projet et déteste même MS pour avoir publié une telle chose !!!

Que représente var lorsqu'une requête est exécutée?

Est - il iQueryable, iSingleResult, iMultipleResultou le fait changer en fonction du la mise en œuvre. Il y a des spéculations sur l'utilisation (ce qui semble être) du typage dynamique par rapport au typage statique standard en C #.

Je pense que tout le monde ne comprend pas à quel point il est facile d'imbriquer une boucle.

Par exemple:

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

group by me fait encore tourner la tête.

Toute confusion concernant une exécution différée devrait pouvoir être résolue en parcourant un code simple basé sur LINQ et en jouant dans la fenêtre de surveillance.

Requêtes compilées

Le fait que vous ne puissiez pas chaîner IQueryablecar ce sont des appels de méthode (alors qu'il n'y a rien d'autre que SQL traduisible!) Et qu'il est presque impossible de contourner cela est ahurissant et crée une énorme violation de DRY. J'ai besoin de mon IQueryablepour ad-hoc dans lequel je n'ai pas de requêtes compilées (je n'ai que des requêtes compilées pour les scénarios lourds), mais dans les requêtes compilées, je ne peux pas les utiliser et à la place, j'ai besoin d'écrire à nouveau la syntaxe de requête régulière. Maintenant, je fais les mêmes sous-requêtes à 2 endroits, je dois me rappeler de mettre à jour les deux si quelque chose change, etc. Un cauchemar.

Je pense que l'idée fausse n ° 1 sur LINQ to SQL est que vous DEVEZ TOUJOURS CONNAÎTRE SQL afin de l'utiliser efficacement.

Une autre chose mal comprise à propos de Linq to Sql est que vous devez encore abaisser la sécurité de votre base de données au point d'absurdité pour le faire fonctionner.

Un troisième point est que l'utilisation de Linq à Sql avec des classes dynamiques (ce qui signifie que la définition de classe est créée au moment de l'exécution) provoque une énorme quantité de compilation juste à temps. Ce qui peut absolument tuer les performances.

Chargement paresseux.

Comme mentionné, chargement paresseux et exécution différée

En quoi LINQ to Objects et LINQ to XML (IEnumerable) sont différents de LINQ to SQL (IQueryable)

COMMENT créer une couche d'accès aux données, une couche métier et une couche de présentation avec LINQ dans toutes les couches ... et un bon exemple.

Comme la plupart des gens l'ont dit, je pense que la partie la plus mal comprise est de supposer que LINQ est juste un remplacement pour T-SQL. Mon manager qui se considère comme un gourou de TSQL ne nous laisserait pas utiliser LINQ dans notre projet et déteste même MS pour avoir publié une telle chose !!!

Transactions (sans utiliser TransactionScope)