说说IUnitOfWork~Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事

  1. 云栖社区>
  2. 博客>
  3. 正文

说说IUnitOfWork~Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事

mcy247 2017-12-06 12:17:00 浏览1109
展开阅读全文
第一讲 认识IUnitOfWork,为什么要出现IUnitOfWork接口第二讲 Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事第三讲 方法完整性与统一提交不冲突第四讲 DbContext对象的创建应该向BLL层公开第五讲 我的IUnitOfWork+Repository架构

     对于微软推出的linq to sql和entity frameworks这两大ORM工具,它为我们的程序开发推供的是操作简单,程序结构清晰,代码量少,但在性能上,往往是开发者议论的焦点的,确实,有时这些ORM工具的不可控与操作不透明性广泛被开发者所关注和注意。

说在前:

通过sql profiler进行检测后,发展LINQ生成的SQL代码确实不是我们所能接受的,3个操作,明明是被TransactionScope括起来组成的一个整体,却向SQL服务器建立了3个连接池,这是为啥?

想在后:

事实上,如果你好好看了MSDN,好好分析了自己写的代码及微软官方的代码,你就不难发现,确实是我们自己的代码有些问题,在一个操作中,(我们称为一个工作单元中),往往我们的submitchages(linq to sql)或者savechanges(ef)的次数是根据你操作方法的数量决定的,这被我们称为操作方法的原子性或者方法的完整性,是,这都没问题,一个方法完完整整的干一件事,有始有终,这也是正常的,但对于ORM工具来说,它不知道你的业务是什么,它也不知道你的方法是什么,它只认识自己的提交语句(submtchanges,savechanges),看到了它们,ORM就马上将LINQ语句翻译为SQL,并建立链接,发送语句到SQL服务器,这也是可以理解的。

有了想法,才有可能改变:

我们从上图的图中可以看到问题,业务层一个方法,调用DAL层两个独立的方法,DAL层两个方法使用LINQ上下文也是各自独立的,所以,向SQL服务器发消息,肯定也是各自完成的,这时性能问题就出来了,优化它的方法是将LINQ上下文通过面向对象的知识,注入到DAL层,使ProductRepository和UserRepository共用一个LINQ上下文,这时,它们由一个上下文来完成这个提交动作,所产生的SQL链接当然也就变成了一个,这就是UnitOfWork的思想,即工作单元!

OK,看到上面的图,我想大家已经明白了,我们的优化完成了,将多个LINQ上下文和成了一个,将与SQL服务器建立的链接次数降低到1次,这时很多服务,程序性能问题也都很好的解决了,呵呵,下次我们将会说一下,如何让各各repository对象中使用同一个上下文!

敬请期待!

本文转自博客园张占岭(仓储大叔)的博客,原文链接:说说IUnitOfWork~Linq to Sql与EntityFrameworks中的SubmtChanges()发生了什么事,如需转载请自行联系原博主。

网友评论

登录后评论
0/500
评论
mcy247
+ 关注