LINQ - la syntaxe de la Requête vs méthode des chaînes & lambda

Quelqu'un bâton à toutes les règles (ou vous êtes forcé de s'en tenir à toutes les règles par votre employeur?) lors du choix d'utiliser LINQ la syntaxe de la requête ou d'une expression Lambda à l'intérieur de l'un des LINQ méthodes d'extension? Cela s'applique à toutes les Entités, SQL, d'objets, de quoi que ce soit.

Sur notre lieu de travail, mon patron n'aime pas lambda, et il avait à utiliser la syntaxe de la requête pour rien, qui, dans certains cas, que je trouve sont de moins en moins lisible.

var names = collection.Select(item => item.Name);

var names = from item in collection
            select item.Name;

Peut-être lors de l'ajout d'une condition, le Lambda je trouve est un peu en désordre, où la

var names = collection.Where(item => item.Name == "Fred")
                      .Select(item => item.Name);

var names = from item in collection
            where item.Name == "Fred"
            select item.Name;

Vient de sortir d'intérêt: comment le compilateur de traiter celui-ci? Personne ne sait comment le au-dessus d'une requête LINQ de compiler en lambda? Sera le Name bien être appelée pour chaque élément? Pourrions-nous faire de ce lieu et potentiellement améliorer la performance? Serait-ce à dire lambda est légèrement plus contrôlable en termes de performance?

var names = collection.Select(item => item.Name)
                      .Where(name => name == "Fred");

Certainement lorsque nous commençons à utiliser de plus en plus et les expressions, le lambda devient bordélique et j'aimerais commencer à utiliser la syntaxe de la requête ici.

var names = collection.Where(item => item.Name == "Fred")
                      .OrderBy(item => item.Age)
                      .Select(item => item.Name);

var names = from item in collection
            where item.Name == "Fred"
            order by item.Age
            select item.Name;

Il y a aussi quelques choses que je trouve ne peut être fait avec la syntaxe de la requête. Certains d'entre eux vous pourriez penser que ce serait vraiment simple (en particulier les fonctions d'agrégation), mais non, vous devez ajouter l'un de l'extension LINQ méthodes pour la fin, qui l'omi, de l'apparence plus soignée avec une expression lambda.

var names = collection.Count(item => item.Name == "Fred");

var names = (from item in collection
            where item.Name == "Fred"
            select item).Count()

Même pour certains le simple lambda chaînes, ReSharper suggère-je les convertir en LINQ des requêtes sur.

Une autre personne peut ajouter à cela? Quelqu'un aurait-il de leur propre peu de règles ou ne leur entreprise suggèrent/forcer l'utilisation d'un?

Resharper donne souvent la possibilité de basculer vers l'autre, pas forcément mieux, e.g pour le foreach et vice versa

InformationsquelleAutor Connell | 2011-11-07

.net c#lambda linq linq-query-syntax

36

Pour répondre à votre question au sujet de la traduction, l'expression de la requête sera toujours traduite sur la base des règles sur 7.16 du C# 4 spec (ou l'équivalent en C# 3 spec). Dans l'exemple où vous vous posez la question sur le Name bien, ce n'est pas une question de l'expression de la requête de la traduction - c'est ce que le Select et Where méthodes de faire avec les délégués ou des arbres d'expression qu'ils prennent en tant que paramètres. Parfois, il est logique de faire une projection en avant de la filtrer, parfois pas.

Que pour peu de règles, je n'ai qu'une: l'utilisation de n'importe quelle façon est la plus lisible pour la requête en question. Donc, si la requête changements et "dont la forme est plus lisible" des modifications en même temps, changer la syntaxe utilisée.

Si vous allez utiliser LINQ vous devrait être heureux avec soit la syntaxe, à tout le moins à lire.

Je ont tendance à trouver que les requêtes avec plusieurs variable de portée (par exemple via SelectMany ou Join, ou un let clause) finissent par être plus lisible en utilisant les expressions de requête - mais c'est loin d'être une règle dure et rapide.
- Aussi la syntaxe de la Requête n'offre pas tous les opérateurs.
- Yup, qui tend à être la règle que j'utilise. Je sais que certaines personnes qui me disent que "lambda est mauvais" et pense que je devrais toujours utiliser la syntaxe de la requête.
- Eh bien, ils clairement ne peut pas utiliser tous les opérateurs dans ce cas. Voir s'ils ont des raisons concrètes - je doute qu'ils ont.
- Aussi faire des commentaires sur votre mise à jour. J'ai délibérément laissé de côté Join et GroupBy parce qu'ils ne regardent beaucoup plus lisible comme une requête. Aussi @Jon, avez-vous des commentaires sur le "vient de sortir d'intérêt" bit dans le 4e paragraphe?
- eh bien, ils disent qu'il est tout au sujet de la laideur. Je ne pense que le => regardé laid, quand je démarre sur LINQ, mais je m'y suis habitué maintenant. Vous ne savez pas si ce que je pouvais penser d'une femme de ménage de la syntaxe du C# de l'équipe pourrait avoir utilisé. Peut-être une sorte d'expression de l'inférence et un mot-clé spécial comme le value mot-clé dans une propriété setter aurait l'air plus agréable.
- Mon équipe a couru à travers une question similaire, localement et lorsque nous avons lancé nos comparaisons (seulement avec Linq to SQL), nous avons trouvé que le sql généré et la misl étaient identiques, même avec de petits changements dans la requête structures.
- Je pense que la laideur d'avoir le "d'où l'sélectionnez" lorsque vous êtes que intéressé par l'application d'un filtre est beaucoup plus grande que la laideur de la lambda - et que font-ils faire s'ils veulent d'une surcharge, ce qui n'est pas pris en charge? J'ai déjà abordé le "Juste par intérêt" bit - le compilateur respecte la langue spec, c'est aussi simple que cela.
- Ah, n'a de sens en fait. Je peux comprendre qu'avec un IQueryable. Mais lors de l'utilisation de LINQ to Objects et simplement à l'aide d'un IEnumerable, c'est juste les méthodes d'extension, qui contient le plus souvent un foreach loop et un yield return.
- Pour un exemple de LINQ to Objects mise en œuvre, vous voudrez peut-être lire mon Edulinq de la série, qui porte sur divers aspects de l'exécution et de la mise en œuvre.
- Comme d'habitude, Jon me battre pour le punch. J'aurais dit la même chose: Ça dépend. Préférez la syntaxe qui est plus facile à gérer pour la requête donnée. Comme pour les méthodes non pris en charge, je ferai remarquer que VB n'ont de support de langue pour plus d'expressions de requête (Sauter, Prendre, Distinctes, Agrégation). Un exemple, je vois souvent que je vais ajouter: pour un simple filtre de la projection d'un seul élément, je préfère items.First(i => i.Prop == value) sur (from i in items where i.Prop == value select i).First()
- Lorsque vous commencez à la chaîne d'Extension des Méthodes (en particulier ceux que vous écrivez vous-même), les choses semblent beaucoup plus agréable que de combiner les 2 syntaxe de l'.
- En particulier ceux que vous écrivez vous-même? Je n'ai jamais pensé à le faire avant!
- Oh il y a beaucoup de possibilités de voir morelinq.googlecode.com 🙂
- J'utilise la méthode de la chaîne de partout, sauf pour "rejoindre".
InformationsquelleAutor Jon Skeet

Vous devez vous connecter pour publier un commentaire.