Pourquoi utiliser Expression<Func<T>> plutôt que Func<T> ?

Question

Je comprends les lambdas et les Func y Action délégués. Mais les expressions me laissent perplexe.

Dans quelles circonstances utiliseriez-vous un Expression<Func<T>> plutôt qu'un simple Func<T> ?

Answer 1

Lorsque vous souhaitez traiter les expressions lambda comme des arbres d'expression et regarder à l'intérieur de ceux-ci au lieu de les exécuter. Par exemple, LINQ to SQL récupère l'expression et la convertit en une instruction SQL équivalente qu'il soumet au serveur (au lieu d'exécuter l'expression lambda).

Sur le plan conceptuel, Expression<Func<T>> es complètement différent de Func<T> . Func<T> désigne un delegate qui est en fait un pointeur vers une méthode et Expression<Func<T>> désigne un structure de données arborescente pour une expression lambda. Cette structure arborescente décrit ce que fait une expression lambda plutôt que de passer à l'acte. Il contient essentiellement des données sur la composition des expressions, des variables, des appels de méthode, ... (par exemple, il contient des informations telles que ce lambda est une certaine constante + un certain paramètre). Vous pouvez utiliser cette description pour la convertir en une méthode réelle (avec Expression.Compile ) ou de faire d'autres choses (comme l'exemple LINQ to SQL). Le fait de traiter les lambdas comme des méthodes anonymes et des arbres d'expression est purement lié à la compilation.

Func<int> myFunc = () => 10; // similar to: int myAnonMethod() { return 10; }

sera effectivement compilée en une méthode IL qui ne reçoit rien et renvoie 10.

Expression<Func<int>> myExpression = () => 10;

sera convertie en une structure de données décrivant une expression qui ne reçoit aucun paramètre et renvoie la valeur 10 :

Agrandir l'image

Bien qu'ils aient tous deux la même apparence au moment de la compilation, ce que le compilateur génère est totalement différent .

Answer 2

Une considération extrêmement importante dans le choix entre Expression et Func est que les fournisseurs IQueryable comme LINQ to Entities peuvent 'digérer' ce que vous passez dans une Expression, mais ignoreront ce que vous passez dans un Func. J'ai publié deux articles de blog sur le sujet :

En savoir plus sur Expression vs Func avec Entity Framework y Tomber amoureux de LINQ - Partie 7 : Expressions et fonctions (la dernière section)

Answer 3

J'aimerais ajouter quelques notes sur les différences entre Func<T> y Expression<Func<T>> :

• Func<T> est juste un MulticastDelegate normal de la vieille école ;
• Expression<Func<T>> est une représentation de l'expression lambda sous la forme d'un arbre d'expression ;
• peut être construit à l'aide de la syntaxe des expressions lambda ou de la syntaxe de l'API ;
• peut être compilé en un délégué Func<T> ;
• la conversion inverse est théoriquement possible, mais il s'agit d'une sorte de décompilation, il n'y a pas de fonctionnalité intégrée pour cela car ce n'est pas un processus simple ;
• L'arbre d'expression peut être observé/traduit/modifié par l'intermédiaire de l'arbre d'expression. ExpressionVisitor ;
• les méthodes d'extension de IEnumerable fonctionnent avec Func<T> ;
• les méthodes d'extension de IQueryable fonctionnent avec Expression<Func<T>> .

Il y a un article qui décrit les détails avec des exemples de code :
LINQ : Func<T> vs. Expression<Func<T>> .

J'espère que cela vous sera utile.

Answer 4

LINQ en est l'exemple canonique (par exemple, pour communiquer avec une base de données), mais en réalité, chaque fois que vous vous souciez davantage de l'expression de l'information, vous pouvez utiliser la méthode ce que à faire, plutôt que de le faire réellement. Par exemple, j'utilise cette approche dans la pile RPC de protobuf-net (pour éviter la génération de code, etc.) - vous appelez donc une méthode avec :

string result = client.Invoke(svc => svc.SomeMethod(arg1, arg2, ...));

Cette opération déconstruit l'arbre d'expression pour résoudre les problèmes suivants SomeMethod (et la valeur de chaque argument), effectue l'appel RPC, met à jour les éventuels ref / out et renvoie le résultat de l'appel à distance. Cela n'est possible que via l'arbre d'expression. J'en parle plus en détail aquí .

Un autre exemple est celui où vous construisez manuellement les arbres d'expression dans le but de les compiler en une lambda, comme le fait l'option opérateurs génériques code.

Answer 5

Vous utiliserez une expression lorsque vous voudrez traiter votre fonction comme des données et non comme du code. Vous pouvez le faire si vous souhaitez manipuler le code (en tant que données). La plupart du temps, si vous ne voyez pas l'utilité des expressions, vous n'avez probablement pas besoin d'en utiliser.