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

回到目录

第一讲 认识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对象中使用同一个上下文！

敬请期待！

回到目录