Puis-je simplifier cette déclaration avec une expression Lambda?
4 Réponses :
Honnêtement, ça me semble très clair. Je pense qu'un lambda dans ce cas peut être moins lisible, c'est-à-dire quelque chose comme Brandon posté ci-dessous.
(volé de Brandon's Post) p>
var project = accounts.Select(a => a.AccountProjects)
.Where(x => x.AccountProjectID == accountProjectId);
Cela dépend de la façon dont vous l'écrivez - ajoutez une pause de ligne avant ". Où" et soudainement, la Lambda est en fait assez lisible.
Je suis en train d'accord avec Ed. Ce que vous avez maintenant est parfaitement lisible, une Lambda ne simplifie pas vraiment quoi que ce soit. Ce serait probablement une question de préférence si quelque chose.
Même avec la pause de la ligne, c'est toujours moins lisible, mais je suppose que c'est une chose subjective. Je suppose que le point est; Il est parfaitement clair, passez à un vrai problème! :)
"Quelques boucles" n'est pas la même chose que la requête Linq. La requête LINQ (de même que la Lambda) permet une exécution différée, où la solution "couple de boucles" ne le fait pas.
De plus, la Lambda dans cette réponse n'est pas correcte, car la même raison que Brandon n'est pas correcte (vous avez réellement admis que vous «volez» de lui).
Supprimé mon message d'origine, car Mark est correct. Ma réponse n'était pas l'équivalent de la requête OPS. Aussi marque, je pense que Ed signifiait la "volée" comme une blague.
@Mark, je pense que vous manquez en partie du point de son poste. Il ne dit pas d'utiliser une lambda et de donner ma réponse (incorrecte) comme une solution, hes suggérant que la commutation de ce qu'il a maintenant à une Lambda ne donnerait aucune prestation de lisibilité. (Eh bien, en fonction de votre préférence)
Ooh, tu es correct. Il a juste utilisé votre Lambda comme exemple. Gotcha, je suis clair maintenant.
@Mark: Vous êtes correct sur la solution de boucle qui ne sont pas sémantiquement la même chose que la solution LINQ / LABMDA. Honnêtement, je ne connais pas beaucoup de Linq parce que nous sommes toujours un .net 2.0 Boutique ici et, alors que j'ai fait de la lecture de soem, je n'ai jamais utilisé la fonctionnalité. Merci d'avoir fait remarquer cela.
var project = accounts.SelectMany(a => a.AccountProjects)
.Where(x => x.AccountProjectID == accountProjectId);
Whether this is actually simpler is a matter of taste.
Je pense que de multiples clauses sont plus simples que la Selectmany implicitement aplatissement, mais peu importe ce que l'ensemble du point de la syntaxe Linq ne donne-t-il pas une syntaxe plus propre que ces méthodes chaînées?
Les deux approches sont de l'équivalent conceptuellement. Ils font exactement la même chose. Ils sont deux façons différentes d'exprimer exactement les mêmes ensembles d'opérations. Comme je l'ai noté dans ma réponse, que vous trouvez «nettoyant» ou «plus simple» est une question de goût.
Je suis d'accord avec Ed Swangren. Ceci semble assez concis et lisible.
La réponse à votre question dépend de 3 choses:
Si vous voulez de meilleures performances, et dans la case «Comptes» est une liste et que la collection résultante sera itératée ou transmise à une autre méthode pour itération suffisamment de ces lignes de code, je ferais quelque chose comme que: C'est sûrement moins lisible que votre déclaration Linq, mais j'utiliserais ces 2 lignes plutôt que des comptes ....... < P> Et sûrement, il est bien mieux optimisé pour la performance, qui est toujours important, je crois.
Quel est l'avantage de celui-ci sur l'appelant tolist () sur la requête LINQ?
La question ne vous a pas demandé de l'optimiser, elle vous a demandé de le simplifier. Vous faites également une assez grande hypothèse lorsque vous dites que c'est «beaucoup mieux optimisé pour la performance». Avez-vous réellement testé? Avez-vous des données pour sauvegarder votre hypothèse?
1. Qu'est-ce que vous appelez la simplification - est une question de goût. Je pense avoir répondu à cette question dans mon précédent post. 2. Bien sûr que je l'ai testé. Autrevise je ne le posterais pas. Le problème n'est pas en appelant TOLIST dans la requête. En moyenne, Linq aux objets est plus de deux fois lentement que les techniques traditionnelles (par exemple, itération à l'aide du cycle de foresach). Ne me croyez pas? Vous pouvez facilement le micro-reportez-vous de Google IT. Et la méthode d'extension foreach utilisée ici avec l'expression de Lambda vous donne une meilleure performance que pour le cycle. Je mets tout à fait un effort pour étudier ce que les choses coûtent, crois-moi
Vous avez également fait la même erreur que les autres réponses, au fait. Votre code n'est pas du tout équivalent au code de l'OP. Compte n'a pas de propriété de compteProjectid, il possède une propriété appelée COMPTHEJECTION, qui est un iNeumable
accounts
.SelectMany (
a => AccountProjects,
(a, ct) =>
new
{
a = a,
ap = ap
}
)
.Where (t => (t.ap.AccountProjectID == t.a.accountProjectId))
.Select (t => t.ap)