83

As an example, why do most LINQ operators accept Expression<Func<TSource>> and its equivalent Func<TSource>?

What's the benefit/reason for using the generic Expression class instead of straight up lambda syntax?

Mark Hurd
  • 10,665
  • 10
  • 68
  • 101
Razor
  • 17,271
  • 25
  • 91
  • 138

4 Answers4

67

Using Expression<T> you are explicitly creating an expression tree - this means that you can deal with the code that makes up the query as if it were data.

The reason for this is that LINQ providers (like LINQ to SQL for example) inspect the query itself to determine the best way to translate the C# expressions into a T-SQL query. Since an expression tree lets you look at the code as data the provider is able to do this.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • 6
    Don't forget that Expression Trees are not exclusive to LINQ providers anymore - for example, they're one of the main underlying concepts of the Dynamic Language Runtime. – Tamas Czinege Apr 19 '10 at 02:13
36

In summary, the key differences between the two are following:

  • Expression<Func<...>> is an expression tree which represents the original source code (it is stored in a tree-like data structure that is very close to the original C# code). In this form, you can analyze the source code and tools like LINQ to SQL can translate the expression tree (source code) to other languages (e.g. SQL in case of LINQ to SQL, but you could also target e.g. JavaScript).

  • Func<...> is an ordinary delegate that you can execute. In this case, the compiler compiles the body of the function to intermediate language (IL) just like when compiling standard method.

It is worth mentioning that Expression<..> has a Compile method that compiles the expression at run-time and generates Func<...>, so there is conversion from the first one to the second one (with some performance cost). However, there is no conversion from the second one to the first one, because once you get IL, it is very difficult (impossible) to reconstruct the original source code.

masoud ramezani
  • 22,228
  • 29
  • 98
  • 151
Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • 1
    Does this mean there will be some sort of compilation at runtime when using an expression tree or is it normally only used to translate the code tree to another language? – Rodi May 04 '11 at 05:45
  • @Rodi: The expression tree can be used in both ways. Typically, it is translated to some other language (e.g. SQL), but it is also possible to compile it. I haven't seen many providers that need to compile expression trees though. – Tomas Petricek May 04 '11 at 14:23
  • So this means when you declare a lambda on the RHS of = then the conpiler is actually looking at the LHS to decide whether it should compile that lambda or leave it as an expression tree? – AaronLS Oct 02 '14 at 17:28
22

Func<T> creates an executable function.

Expression<Func<T>> creates an expression tree that allows you to work with the code in the function as data.

Expression Trees allow you to do things like LINQ to SQL and LINQ to XML by generating the underlying calls from your .NET code.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
7

An Expression<Func<>> is the representation of a function that has yet to be turned into code. A Func<> is an actual executable function. Using the former allows you to turn the expression into the appropriate function at the time that it is invoked. For example, with LINQ to SQL this will translate it into a the equivalent code to execute a SQL statement and return the specified contents. With LINQ to objects, it will execute code on the client using the CLR. A Func<> is always executed in the CLR -- it's executable code.

tvanfosson
  • 524,688
  • 99
  • 697
  • 795