[解決済み】なぜFunc<T>ではなくExpression<Func<T>を使うのですか？

質問

私はラムダを理解し Func と Action のデリゲートです。しかし式は を使うのは難しいです。

どのような状況で Expression<Func<T>> ではなく、古い Func<T> ?

解決方法は？

ラムダ式を式木として扱い、実行するのではなく、その中を見たいとき。例えば、LINQ to SQLが式を取得し、同等のSQL文に変換してサーバーに送信する（ラムダを実行するのではない）。

概念的に Expression<Func<T>> は 全く異なる から Func<T> . Func<T> を表します。 delegate へのポインタのようなものです。 Expression<Func<T>> を表します。 ツリーデータ構造 をラムダ式に置き換えたものです。この木構造 は、ラムダ式が何を行うかを記述しています。 を行うのではなく、実際に行うのです。基本的には、式、変数、メソッドコールなどの構成に関するデータを保持します（例えば、このラムダはある定数＋あるパラメータであるというような情報を保持します）。この記述を使って、実際のメソッドに変換することができます ( Expression.Compile あるいは、LINQ to SQLの例のように）他のことをすることもできます。ラムダを無名メソッドや式木として扱う行為は、純粋にコンパイル時のものです。

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

は事実上、何も得られず10を返すILメソッドにコンパイルされます。

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

は、パラメータを取らずに値10を返す式を記述したデータ構造に変換されます。

拡大画像

コンパイル時にはどちらも同じに見えますが、コンパイラが生成するのは 全く異なる .