9 Answers
9

Expression tree are so powerful because they let you treat code like data. Users are accustomed to building up data, saving it and coming back to it later.

Expression trees let you do the same thing with code. For example you can take your user's input (check-boxes, number ranges, etc.) and translate it into an Expression tree. That expression tree can then be executed, or stored off for later use. Very cool.

Think of the practical uses around reporting like building up and saving data filters and data mappings. Another practical use would be to support custom work flows in your application based on user defined rules.

Cool! This is an answer that fits my particular mindset. Nice examples! I see now how this is used in other parts of the framework. So then is this used a lot in WPF?
–
KevinDeusOct 7 '09 at 17:52

Thanks. Glad that helped. I’ve thought (probably too much) about WPF and how crazy useful functional programming concepts like lambdas and expression trees would have been at the core. Problem is WPF was released with .NET 3.0 and LINQ was released in .NET 3.5. Going forward I would hope the WPF/Silverlight teams will retool. XAML would be OK except for all the darn strings :). Fire up Relector and see what they had to do for things like System.Windows.DataTrigger. Their lamentation may have been a catalyst for LINQ.
–
Bryan HunterOct 7 '09 at 19:28

The quick answer is "no, it's not just for LINQ providers now". First, expression trees were extended by the dynamic language runtime to support dynamic languages. Basically, if you want to port your own dynamic language to .NET (like IronPython and IronRuby did), you will have to use expression trees.
OK, not so many people have their own languages. What are other use cases? One of them is to generate dynamic code at run time. I have an example here: Generating Dynamic Methods with Expression Trees in Visual Studio 2010. It explains how you can use ETs instead of generating MSIL in order to create dynamic methods.
In fact, there are some use cases for Expression Trees outside of LINQ even in .NET 3.5, but those posts are yet to be written.

I've had a good experience with them transforming my domain specific language ASTs into expression trees. It is also fairly easy with an ANTLR tree adaptor to create an Expression tree directly from the grammar.

You can use expression tree as a code builder with a higher abstraction level then assembly emit and faster then CodeCompiler. Here is some proof of the concept that i used to convince our team to use them as a replacement for CodeCompiler.