+2  A: 

Here's an article which explains the basics...

In short:

1) Basically, yes it's an in-memory representation of the logic.

2) It can be compiled to MSIL (or, like in the case of LINQ-to-SQL also to other languages).

3) The Func<> delegates are used because they are used to represent the expression as callable function (which is internally compiles as MSIL).

Lucero
in reality though, the Func<> (and corresponding Action<> delegates) are just there for convenience. You can use any delegate type
Joel Martinez
OMG! That's the tutorial where I understood Expression Trees!!
yelinna
+1  A: 

I'm not an expert on the subject but I'll try to clear the way.

Think of expression-trees as a typed reflection. It is an easy way to get to know what a function has, like what's the operand, parameters and stuff.

So,
1) I would say yeap.
2) Not exactly... you should learn the feature first (me too) and then find what it is good for. Are you generating code? that to me could be a very useful feature of the expression-trees
3) Expression-tree it is a new feature but there's nothing you couldn't do before. Now it's just easier.

There's a good article here which explains the basics.

sebastian
@Lucero, I'm glad we both posted the same link :)
sebastian
Everybody loves Charlie's Expression Tree Basics :D
yelinna
+8  A: 

Expression tree represent a syntax tree of a single expression.

Each node of tree represent some constant, object member reference or operation.

E.g. for expression 2 + 3 we can build and expression tree:

Expression.MakeBinary(
    ExpressionType.Add,
    Expression.Constant(2),
    Expression.Constant(3));

The most important of such trees is Expression which allows to write expression in nice readable form reminding lambda functions of signature matching TDelegate. Here's ex

Expression<Func<int>> sum = () => 2 + 3; // much nicer, eh?

But Expression is not delegate, since it couldn't be executed directly.

Instead it can be traversed e.g. with visitor object to build some executable representation. Examples could be delegate build with Expression.Compile() or SQL query built from LINQ query using CompiledQuery.Compile() etc.

Another useful application of expression trees is using them to represent members of objects that otherwise would require usage of Reflection. Reflection uses strings to represent member names and makes no checks at compile time. Expression trees are checked, so a little less errors could be made.

PropertyInfo prop1 = typeof(MyClass).GetProperty("Value");

Expression<Func<MyClass, int>> expr = mc => mc.Value;
PropertyInfo prop2 = (mc.Body as MemberExpression).Member as PropertyInfo;
elder_george
+1 really good explanation :-)
Joel Martinez
+4  A: 

Expression is a versatile way of expressing code operations as an object model. This is extended much more in 4.0, but this is an area I use a lot; I have some blog points here, or another attempt at explaining it all on InfoQ. I've also presented this subject a few times - perhaps try the download here (but it won't make as much sense without the words; sorry).

I'll be honest; it isn't a simple subject - but it is hugely powerful when you grok it. From the above, I'd probably start with the InfoQ.

Marc Gravell
+1  A: 

I have tried to answer questions like yours on C# FAQ blog in the following blog post: Generating Dynamic Methods with Expression Trees in Visual Studio 2010. So, yes, it is in-memory. I don't understand what you mean by "user-defined patterns", but you can use it to write dynamic code. And no, you can't replace ETs with delegates, becuase you can't modify delegates at run-time. The only substituion can be MSIL, which is much harder to read and write.

Alexandra Rusina