Timothy's Space君看一叶舟,出没风波里
Linq to Sql 之延迟加载与立即加载
590 views 十二月 20, 09 by TimothyLinq的延迟加载
Linq to Sql中默认采用的模式就是延迟执行,所谓延迟执行,其实就是在获取对象本身时,并不会获取和其关联的其他对象,只有在访问其关联对象的时候,程序才会去加载关联对象的数据到内存中。这样的好处是程序不会在初次访问的时候,就加载大批量的数据,而是以一种延迟加载的方式进行处理,相对而言,对于系统和网络的性能开支会减小很多。对于一个默认的Linq to Sql查询,延迟加载就是其默认的设置,不过,在某些情况下,延迟加载并非完全“智能”,不但没有实现其本意,反而增大了网络流量和性能开支。下面我们以SQL Server中的演示数据库NorthWind来试验一下:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
通过Linq to sql查询所有OrderID为10251的订单信息,并输出订单编号和订单日期。通过显示Linq的日志输出,我们可以看到后台生成的SQL语句如下:
1 2 3 4 5 6 | |
输出的SQL看来还比较正常。下面我们再来改一下我们的程序:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | |
出了输出订单相关信息外,还输出其关联对象:客户姓名、订单中的产品编号、单价、数量
再来看看输出的SQL语句:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | |
我们可以看到,对于我们修改后的代码,程序向数据库请求了三条SQL语句,当然,这还不是最坏的情况,但是我们在这里的确看到延迟加载似乎“变了味道”,不但没有节省开支,反而增大了网络浏览。怎样才能改善这样的情况呢?
关于立即加载
其实我们知道,有很多扩展方法会导致延迟加载失效,而开始立即执行。当我们在调用诸如:ToList、ToDictionary、ToLookup或者ToArray之类的扩展方法之后,程序会将最终的结果存放到某个临时的变量集合中,并让所有的数据一次性的加载完成。
另外,还有一种方式,通过设置DataContext的DeferredLoadingEnabled属性为false,显示的关闭默认的延迟加载方式。
1 2 | |
这些方式虽然比较方便,但是还是有一定的局限性。例如,简单的使用ToList只能解决一些简单的查询问题,而对于复杂的查询需求,ToList还是不能解决延迟取得子对象所引发的多次查询问题。并且,在大量数据被加载到内存中的时候,对内存的需求也是很大的。不过,幸好Linq to sql给我们提供了另外一套不错的方法。
使用DataLoadOptions实现对加载对象的优化
Linq to Sql提供DataLoadOptions,用以立即加载关联的对象数据,其中包含两种方法:
LoadWith方法,用于立即加载与主对象相关联的数据
AssociateWith方法,用于对关联对象的数据进行筛选,并加载
有了DataLoadOptions,我们就可以用如下的方式优化我们的查询中需要加载的对象:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | |
对于我们开发者而言,需要注意的是,对于同一个DataContext实例,DataLoadOptions只能设定一次,并且一旦设定,就无法更改。
接下来,运行程序,看看优化后,程序向数据库服务器请求的的SQL:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
可以看出,之前的分三次向数据库提交sql的情况,现在被程序优化为一条带LEFT JOIN的关联查询,而获取关联数据。三次SQL请求,被优化为一次,从而减少了数据库和网络流量开支,由此看来DataLoadOptions的好处不言而喻。
一点小结
延迟加载与立即加载,并无孰优孰劣之区别,在某些情况下,需要我们根据自己的需求和实际情况来选择来进行选择。
声明: 此Blog中的文章和随笔仅代表作者在某一特定时间内的观点和结论,对其完全的正确不做任何担保或假设
本站文章均采用 知识共享署名-相同方式共享3.0 协议进行授权,除非注明,本站文章均为原创,转载请注明转自 Timothy's Space 并应以链接形式标明本文地址!