打造自己的LINQ Provider（上）：Expression Tree揭秘

在.NET Framework 3.5中提供了LINQ 支持后，LINQ就以其强大而优雅的编程方式赢得了开发人员的喜爱，而各种LINQ Provider更是满天飞，如LINQ to NHibernate、LINQ to Google等，大有“一切皆LINQ”的趋势。LINQ本身也提供了很好的扩展性，使得我们可以轻松的编写属于自己的LINQ Provider。

本文为打造自己的LINQ Provider系列文章第一篇，主要介绍表达式目录树（Expression Tree）的相关知识。

究竟什么是表达式目录树（Expression Tree），它是一种抽象语法树或者说它是一种数据结构，通过解析表达式目录树，可以实现我们一些特定的功能（后面会说到），我们首先来看看如何构造出一个表达式目录树，最简单的方法莫过于使用Lambda表达式，看下面的代码：

<a href="http://11011.net/software/vspaste"></a>

在我们将Lambda表达式指定给Expression&lt;TDelegate&gt;类型的变量（参数）时，编译器将会发出生成表达式目录树的指令，如上面这段代码中的Lambda表达式(a, b) =&gt; a * b + 2将创建一个表达式目录树，它表示的是一种数据结构，即我们把一行代码用数据结构的形式表示了出来，具体来说最终构造出来的表达式目录树形状如下图所示：

这里每一个节点都表示一个表达式，可能是一个二元运算，也可能是一个常量或者参数等，如上图中的ParameterExpression就是一个参数表达式，ConstantExpression是一个常量表达式，BinaryExpression是一个二元表达式。我们也可以在Visual Studio中使用Expression Tree Visualizer来查看该表达式目录树：

查看结果如下图所示：

<a href="http://images.cnblogs.com/cnblogs_com/Terrylee/WindowsLiveWriter/LINQProvider_12290/TerryLee_0162_2.png"></a>

<a href="http://images.cnblogs.com/cnblogs_com/Terrylee/WindowsLiveWriter/LINQProvider_12290/TerryLee_0161_2.png"></a>

它们都继承于抽象的基类Expression，而泛型的Expression&lt;TDelegate&gt;则继承于LambdaExpression。在Expression类中提供了大量的工厂方法，这些方法负责创建以上各种表达式对象，如调用Add()方法将创建一个表示不进行溢出检查的算术加法运算的BinaryExpression对象，调用Lambda方法将创建一个表示lambda 表达式的LambdaExpression对象，具体提供的方法大家可以查阅MSDN。上面构造表达式目录树时我们使用了Lambda表达式，现在我们看一下如何通过这些表达式对象手工构造出一个表达式目录树，如下代码所示：

这里构造的表达式目录树，仍然如下图所示：

运行这段代码，看看输出了什么：

可以看到，通过手工构造的方式，我们确实构造出了同前面一样的Lambda表达式。对于一个表达式目录树来说，它有几个比较重要的属性：

Body：指表达式的主体部分；

Parameters：指表达式的参数；

NodeType：指表达式的节点类型，如在上面的例子中，它的节点类型是Lambda；

Type：指表达式的静态类型，在上面的例子中，Type为Fun&lt;int,int,int&gt;。

在Expression Tree Visualizer中，我们可以看到表达式目录树的相关属性，如下图所示：

大家可能经常看到如下这样的语言，其中第一句是直接用Lambda表达式来初始化了Func委托，而第二句则使用Lambda表达式来构造了一个表达式目录树，它们之间的区别是什么呢？

其实看一下IL就很明显，其中第一句直接将Lambda表达式直接编译成了IL，如下代码所示：

而第二句，由于告诉编译器是一个表达式目录树，所以编译器会分析该Lambda表达式，并生成表示该Lambda表达式的表达式目录树，即它与我们手工创建表达式目录树所生成的IL是一致的，如下代码所示，此处为了节省空间省略掉了部分代码：

现在相信大家都看明白了，这里讲解它们的区别主要是为了加深大家对于表达式目录树的区别。

前面已经可以构造出一个表达式目录树了，现在看看如何去执行表达式目录树。我们需要调用Compile方法来创建一个可执行委托，并且调用该委托，如下面的代码：

运行后输出的结果：

这里我们只要简单的调用Compile方法就可以了，事实上在.NET Framework中是调用了一个名为ExpressionCompiler的内部类来做表达式目录树的执行（注意此处的Compiler不等同于编译器的编译）。另外，只能执行表示Lambda表达式的表达式目录树，即LambdaExpression或者Expression&lt;TDelegate&gt;类型。如果表达式目录树不是表示Lambda表达式，需要调用Lambda方法创建一个新的表达式。如下面的代码：

输出后为：

<a href="http://images.cnblogs.com/cnblogs_com/Terrylee/WindowsLiveWriter/LINQProvider_12290/TerryLee_0164_2.png"></a>

现在我们想要修改表达式目录树，让它表示的Lambda表达式为(a,b)=&gt;(a - (b * 2))，这时就需要编写自己的表达式目录树访问器，如下代码所示：

使用表达式目录树访问器来修改表达式目录树，如下代码所示：

似乎我们是修改表达式目录树，其实也不全对，我们只是修改表达式目录树的一个副本而已，因为表达式目录树是不可变的，我们不能直接修改表达式目录树，看看上面的OperationsVisitor类的实现大家就知道了，在修改过程中复制了表达式目录树的节点。

通过前面的介绍，相信大家对于表达式目录树已经有些了解了，还有一个很重要的问题，就是为什么需要表达式目录树？在本文开始时，就说过通过解析表达式目录树，可以实现我们一些特定的功能，就拿LINQ to SQL为例，看下面这幅图：

当我们在C#语言中编写一个查询表达式时，它将返回一个IQueryable类型的值，在该类型中包含了两个很重要的属性Expression和Provider，如下面的代码：

我们编写的查询表达式，将封装为一种抽象的数据结构，这个数据结构就是表达式目录树，当我们在使用上面返回的值时，编译器将会以该值所期望的方式进行翻译，这种方式就是由Expression和Provider来决定。可以看到，这样将会非常的灵活且具有良好的可扩展性，有了表达式目录树，可以自由的编写自己的Provider，去查询我们希望的数据源。经常说LINQ为访问各种不同的数据源提供了一种统一的编程方式，其奥秘就在这里。然而需要注意的是LINQ to Objects并不需要任何特定的LINQ Provider，因为它并不翻译为表达式目录树，后面会说到这一点。

本文转自lihuijun51CTO博客，原文链接：http://blog.51cto.com/terrylee/90559 ，如需转载请自行联系原作者