.NET深入解析LINQ框架（五：IQueryable、IQueryProvider接口详解)

阅读目录：

1.环路执行对象模型、碎片化执行模型(假递归式调用)

2.N层对象执行模型(纵横向对比链式扩展方法)

3.LINQ查询表达式和链式查询方法其实都是空壳子

4.详细的对象结构图(对象的执行原理)

5.IQueryable<T>与IQueryProvider一对一的关系能否改成一对多的关系

6.完整的自定义查询

1】. 环路执行对象模型、碎片化执行模型(假递归式调用)

这个主题扯的可能有点远，但是它关系着整个LINQ框架的设计结构，至少在我还没有搞懂LINQ的本意之前，在我脑海里一直频频出现这样的模型，这些模型帮助我理解LINQ的设计原理。其实在最早接触环路模型和碎片化模型是在前两个月，那个时候有幸接触企业应用架构方面的知识，里面就有很多业务碎片化的设计技巧。其实理解这些所谓的设计模型后将大大开阔我们的眼界，毕竟研究框架是要研究它的设计原理，它的存在必然是为了解决某一类问题，问题驱动它的设计模型。所以我们在研究这样的模型的时候其实已经在不知不觉的理解问题的本质。


想必没有人不了解递归的原理，对递归的使用也是很常见的，通过递归算法我们可以解决一下无法解决的大问题，通过将大问题分解成多个同样数据结构的小问题然后让计算机重复的去计算就行了。最为常见的就是遍历树形结构的对象，如：XML，它的每个节点都是一样的对象，所以递归调用的方法也是同一个方法，只不过不断的调用将产生多个调用栈，最后在按照调用顺序的反向出栈就得出一个完整的数据结构。

那么在LINQ中来说，我们无法通过一个方法多次调用来产生我们想要的表达式树，一个Where查询表达式扩展方法可能不仅仅是被LINQ查询表达式所使用，还有可能被ORM的入口方法所使用，比如Update更新的时候就需要Where给出更新的条件，Delete也同样如此。(当然我们这里讨论是LINQ背后的设计原理不单单针对LINQ的技术，而是某一类问题的通用设计模式。)那么我们如何构造出一个类似递归但不是递归的算法结构，方法1可能被方法2调用，方法2也可能被方法1所调用，这样的方法很多，N个方法分别表达不同的语义，具体的构造看使用者的需求，所以这里就出现碎片化的概念了，只有碎片化后才能最大程度的重组，既然能重组了就形成了环路的执行模型。非常完美，看似简单却深不见底的模型我们只了解到冰山一角而已，在企业架构、领域驱动设计方向都已经有着很多成功的案例，要不然也不会被称为设计模式了更为强大的称呼是企业应用架构模式才对。用文字的方式讲解计算机程序问题似乎有点吃力，用代码+图形分析的方式来讲解最适合我们程序员的思维习惯了。下面我用一个简单的例子再附上一些简单的图示来跟大家分享一下这几个模式语言的关系。

大家肯定都知道每逢过年过节都会有很多礼品摆放在超市里商场里买，但是我们都知道一个潜规则，就是这些商品的包装花费了很多功夫，一层套一层，其实里面的东西可能很不起眼，这也是一种营销手段吧。我们暂且不管这里面是什么东西，我们现在要设计一个能够任意进行N层次包装的模型出来，一件商品左一层右一层的反复包装，包装几次我们不管，我们提供能进行N层包装的方法出来就行了。

View Code

using (DbQuery<Order> dbquery = new DbQuery<Order>())
{
var OrderList = from order in dbquery where order.OrderName == "111" select order;
OrderList.Provider.Execute<List<Order>>(OrderList.Expression);//立即执行
foreach (var o in OrderList)
{
//延迟执行
}
}

喜欢编写ORM框架的朋友完全值得花点时间搞一套自己的LINQ TO ORM，这里只是让你高兴一下。

作者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。