J'ajoute une réponse pour les noobs parce que ces réponses semblaient sur ma tête, jusqu'à ce que je réalise à quel point c'est simple. Parfois, vous vous attendez à ce que ce soit compliqué qui vous empêche de «vous envelopper la tête».
Je n'avais pas besoin de comprendre la différence jusqu'à ce que j'entre dans un `` bogue '' vraiment ennuyeux essayant d'utiliser LINQ-to-SQL de manière générique:
public IEnumerable<T> Get(Func<T, bool> conditionLambda){
using(var db = new DbContext()){
return db.Set<T>.Where(conditionLambda);
}
}
Cela a très bien fonctionné jusqu'à ce que je commence à obtenir OutofMemoryExceptions sur des ensembles de données plus importants. Définir des points d'arrêt à l'intérieur du lambda m'a fait réaliser qu'il parcourait chaque ligne de ma table un par un à la recherche de correspondances avec ma condition lambda. Cela m'a bloqué pendant un certain temps, car pourquoi diable traite-t-il ma table de données comme un géant IEnumerable au lieu de faire LINQ-to-SQL comme il est censé le faire? Il faisait également exactement la même chose dans mon homologue LINQ-to-MongoDb.
Le correctif était simplement de Func<T, bool>devenir Expression<Func<T, bool>>, alors j'ai cherché pourquoi il fallait un Expressionau lieu de Func, pour finir ici.
Une expression transforme simplement un délégué en données sur lui-même.Devient a => a + 1alors quelque chose comme "Sur le côté gauche, il y a un int a. Sur le côté droit, vous ajoutez 1". C'est ça. Tu peux rentrer chez toi maintenant. C'est évidemment plus structuré que cela, mais c'est essentiellement tout ce qu'un arbre d'expression est vraiment - rien pour vous envelopper.
En comprenant cela, il devient clair pourquoi LINQ-to-SQL a besoin d'un Expression et un Funcn'est pas adéquat. Funcne porte pas avec lui un moyen d'entrer en lui-même, de voir le détail de la façon de le traduire en une requête SQL / MongoDb / autre. Vous ne pouvez pas voir s'il s'agit d'addition, de multiplication ou de soustraction. Tout ce que vous pouvez faire, c'est l'exécuter. Expression, d'autre part, vous permet de regarder à l'intérieur du délégué et de voir tout ce qu'il veut faire. Cela vous permet de traduire le délégué en ce que vous voulez, comme une requête SQL. Funcn'a pas fonctionné car mon DbContext était aveugle au contenu de l'expression lambda. Pour cette raison, il n'a pas pu transformer l'expression lambda en SQL; cependant, il a fait la meilleure chose suivante et a itéré cette conditionnelle à travers chaque ligne de ma table.
Edit: exposant ma dernière phrase à la demande de John Peter:
IQueryable étend IEnumerable, donc les méthodes IEnumerable comme Where()obtenir des surcharges qui acceptent Expression. Lorsque vous passez un Expressionà cela, vous conservez un IQueryable en conséquence, mais lorsque vous passez un Func, vous retombez sur le IEnumerable de base et vous obtiendrez un IEnumerable en conséquence. En d'autres termes, sans remarquer que vous avez transformé votre ensemble de données en liste à itérer plutôt qu'en quelque chose à interroger. Il est difficile de remarquer une différence jusqu'à ce que vous regardiez vraiment sous le capot les signatures.
une plus grande image