I’ve been working a lot with LINQ over the last few months, trying to approach it sanely with respect to SubSonic. It’s not that it’s terribly difficult to understand – it can simply be overwhelming at times with how much is in there. And whenever you think you know it, you realize that not only were you wrong, you weren’t even in the same universe.
I’m a visual person, and sometimes wrapping my head around a technology involves my “seeing it” in a certain way. Either by a graphic or just a simple outline. LINQ doesn’t offer out of the box and I’ve been writing my expressions out to the console to “see what’s hiding in there”. No longer – I found a really cool tool to use – and it’s already on my machine as part of Visual Studio.
Let’s Get Visual
I was trolling around Google today, thinking that someone MUST have written a routine to barf out the Expression Tree generated by a LINQ statement. If you don’t know what I’m talking about, consider this LINQ statement:
var x = from p in query where p.ProductID == 1 && p.CategoryID == 6 select p;
This statement in particular deals with a database – but let’s forget that for now and just imagine that it’s a query for “something”. What this does is generate a thing called an “Expression Tree” – a recursive tree of objects called Expressions that describe the statement. You can see this if you access the Expression of the statement:
System.Linq.Expressions.Expression expression = x.Expression;
In this statement, “x.Expression” is the entire tree, boxed into the base class of “Expression”. Yes, Expressions can (and are expected to) contain other Expressions and branch out all over the place, creating a tree (more on this in a moment).
Hug (and Visit) a Tree
Working with an Expression tree isn’t easy, and sometimes I feel like a Geek With Very Little Brain. I can think recursively, if I have the right combination of caffeine and jelly beans, but then I get a major geek hangover and have to go mow the lawn or something. This is tough stuff – but there are a lot of examples out there on how to do it appropriately.
I’ve written about this before but when it comes to using LINQ and its constructs you really can’t write enough. The pattern you want to use when you’re dealing with a tree structure is called the Visitor Pattern (from Wikipedia):
In object-oriented programming and software engineering, the visitor design pattern is a way of separating an algorithm from an object structure upon which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. Thus, using the visitor pattern helps conformance with the open/closed principle.
In essence, the visitor allows one to add new virtual functions to a family of classes without modifying the classes themselves; instead, one creates a visitor class that implements all of the appropriate specializations of the virtual function. The visitor takes the instance reference as input, and implements the goal through double dispatch.
If you’ve never dealt with this kind of pattern before – well neither had I until a year or so ago. The pattern seems simple enough, however applying it to a recursive system isn’t the easiest thing. Thankfully, there is an MSDN article on how to do this with Expression Trees and has been something I’ve reread about 100 times. If you want some more, Matt Warren (another blog I read constantly) shows you how to do this in the scope of a SQL call. It’s an amazing read – but give yourself time on this one; Matt’s one of “those guys” who’s brain is in a different dimension and thankfully he’s a very good writer. But it’s not easy stuff.
I Think That I Shall Never See…
I’m tits-deep in implementing “this stuff” for SubSonic right now, and routinely I run into issues where an Expression Tree gets generated for a given query, and I need to decide what type the Expression is, how/where it was generated, and what I need to do with it. For this I’ve used the debugger and immediate window constantly and I’ve wished I could have this all laid out for me visually.
And thankfully Granville Barnett pointed the way. The “Expression Tree Visualizer” is so very cool that I thought it would be a good idea to pass it along to you:
Again, if you have VS 2008, you already have this on your machine – it’s just not hooked up! To hook it up, you need to do a couple of things:
- Pull the code for this thing out of a zip file in your VS install directory
- Compile the project
- Put the DLL into your VS Visualizers directory
It takes just 5 minutes, so let’s get started!
First – find your Samples directory for Visual Studio. Mine was located at
There’s a lot in here – but the file I’m interested in is the CSharpSamples.zip. If you open that you’ll see two directories, one called “Linq Samples”. If you open that you’ll find what we’re looking for! (They didn’t make this easy did they):
Almost there – now just drag this to your Desktop and open it. It’s a VS 2008 solution and you need to open the project and build it. We’re after a single DLL here, and it’s the one in the ExpressionTreeVisualizer project. Once it’s built, grab the ExpressionTreeVisualizer.dll file from the /bin/Debug, and we’re almost done.
Next, find your Visualizers folder for Visual Studio. This should be (by default) in your Docs and Settings directory:
You might not have a Visualizers folder here – if you don’t just create it. Then drop in the ExpressionTreeVisualizer.dll! And that’s it!
Using the Visualizer works like other visualizers (the data visualizer, XML, and text) – just create a stop when debugging, then hover over the Expression variable you want to look at:
Clicking on the Expression Tree Visualizer will bring it up, and you can view your Expression Tree:
