IEnumerable,IQueryable之前世今生
来自于：http://www.cnblogs.com/chengxiaohui/articles/2088967.html
IEnumerable<T>在.Net2.0中我们已经很熟悉了.你想要利用Foreach迭代吗?实现 IEnumerable<T>吧!你想直接做为数据源绑定到控件吗?使用IEnumerable吧!是的.只要是序列.它都实现了 IEnumerable<T>(.Net1.0下的序列类除外).除了这些.LINQ的出现.还赋予了 IEnumerable<T>更强悍的功能.IQueryable<T>继承IEnumerable<T>.详细看 IEnumerable<T>和IQueryable<T>这两个API的签名.可以说非常相似.从某种意义上来说.它们是可以 互换的.但是却不总是可以互相代替的.IEnumerable<T>和IQueryable<T>的行为有所不同.其性能方面也 可能天差地别.例如:
var q = from c in dbContext.Customers
where c.City == "shenzhen"
select c;
var q = (from c in dbContext.Customers
where c.City == "shenzhen"
select c).AsEnumerable();
这两个查询看起来几乎一模一样.查询返回的结果也一样.但他们的实现方式却大相径庭.第一个查询使用了LINQ2SQL的处理方式.第二个查询则使 用了LINQ2Object处理.通过前面的学习.我们知道,LINQ2Object的处理结果是把LINQ表达式映射成对应的委托,而LINQ2SQL 则是保存了一系列的"步骤"---表达式树的处理方式.两者的区别简单的理解就是LINQ2Object将数据存放在内存中.而LINQ2SQL则是把数 据存放在远程的服务器中.
场景模拟
举一个例子.现在有两个水果批发商A,B..A除了是批发商,自己还承包了几个果场.自产自销.B和几个大型的果场合作.只做批发工作.每次客人来A订 货.指定要什么货物,A就可以立刻拿出.速度快.服务佳.缺点是由于是自己的果场.那量肯定不大,而且品种不齐全,小作坊式的经营.B呢?每次客户订 单.B是先把客户需要的货物规格等记录下来.一次性去各个果场取货.这样B的优点就是量大.品种多.但速度可能偏慢(收到货的时间).不过若B以A的销售 方式来销售.那么B的效绩肯定是让人十分不满意,工厂式的经营.
总结之,IEnumerable<T>查询必须在本地执行.并且执行查询前我们必须把所有的数据加载到本地.而且更多的时候.加载的数据有大 量的数据是我们不需要的无效数据.但是我们却不得不传输更多的数据.做更多的无用功.而IQueryable<T>却总能只提供你所需要的数 据.大大减少了数据的传输.这就好比我们在小作坊下订单.小作坊老板跟我们说.他的货刚好比你所需要的多出一些.你只能要了它.不然剩下一点他不好卖等 等.而大工厂却不会出现这种状况.
个性要求
虽说小作坊很多弊病.但有时候却有着大工厂无法媲美的服务.假如你需要一种八种水果组合套餐.大工厂一般不会为你量身定做.单对单服务.相反.小作坊客源有限.一般都会满足你的个人需求.
场景切换:在<<［More Effective C#］Lambda表达式优化>>里我们提到过.LINQ2SQL中是不允许出现自定义方法的.这是由于LINQ2SQL的处理方式.详见<<［More Effective C#］Lambda表达式优化>>.而LINQ2Object却能很好的满足我们自定义方法这个性化的要求.
但是.除了自定义方法.还有一些内置的方法IEnumerable<T>和IQueryable<T>是同时支持的.例如常见的string类的操作方法.substring,indexof等等.
尾声
可能这个例子在这里有些牵强.但相信IEnumerable<T>和IQueryable<T>之间的区别不难理解.更多时候我 们在查询序列的时候.要考虑到底是本地查询好.还是远程查询好.至于哪种查询更好.没有绝对的说法.适合应用环境,已经能发挥最大效应的.那就是最好的.
转自：http://www.dotblogs.com.tw/kongyiyun/archive/2010/10/22/18510.aspx
