ABP源码分析十：Unit Of Work

红尘渡 發表於 2016-3-23 17:48:00

ABP以AOP的方式实现UnitOfWork功能。通过UnitOfWorkRegistrar将UnitOfWorkInterceptor在某个类被注册到IOCContainner的时候，一并添加到该类在容器中对应的ComponentModel的Interceptors集合中。总结一句话就是，UOW的功能是通过自定义Castle拦截器来实现的。本文主要介绍ABP核心框架中的UnitOfWork的实现，后续会分别介绍ABP其他模块是如何具体实现IUnitOfWork的
 
如图，AbpKernelModule调用UnitOfWorkRegister的Initialize方法将UnitOfWorkInterceptor拦截器添加到标注了UnitOfWork特性方法的类，以及实现IRepository或IApplicationService的类上。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230700229-396107268.png" alt="">
 
下图是UnitOfWorkRegister的代码
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230710979-467482243.png" alt="">
 
和通常实现的AOP一样，ABP定义了UnitOfWork特性，方便业务层为方法注入UOW功能。
UnitOfWorkAttribute：用于标注某个方法位UnitOfWork的Attribute类. 通过这个特性，可以指定是否启用UOW，事务隔离级别，TransactionScopeOption等
<img src="https://images2015.cnblogs.com/blog/4776/201604/4776-20160415084800020-1517830407.png" alt="">
UnitOfWorkOptions： 封装了UnitOfWork参数的类，其实例是通过UnitOfWorkAttribute的CreateOptions来生成的。
 
<hr>
 
接下来，分析下UnitOfWork是如何封装事务的。
基于接口隔离原则的考量，ABP作者将UnitOfWork的方法分到了三个不同的接口中，如下图。
IUnitOfWorkCompleteHandle:定义了UOW同步和异步的complete方法。实现UOW完成时候的逻辑。
 
IActiveUnitOfWork：一个UOW除了以上两个接口中定义的方法和属性外，其他的属性和方法都在这个接口定义的。比如Completed，Disposed，Failed事件代理，Filter的enable和disable,以及同步、异步的SaveChanges方法。
 
IUnitOfWork：继承了上面两个接口。定义了外层的IUnitOfWork的引用和UOW的begin方法。 ABP是通过构建一个UnitOfWork的链，将不同的方法纳入到一个事务中（后文解释）。 UnitOfWorkBase：这个抽象类实现了上面三个接口中定义的方法，而真正实现事务控制的方法是由这个抽象类的子类实现的（比如，真正创建TransactionScope的操作是在EfUnitOfWork，NhUnitOfWork这样的之类中实现的）。UOW中除了事务控制逻辑以外的逻辑都是由UnitOfWorkBase抽象类实现的。
 
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230728292-1825372742.png" alt="">
 
ABP中共有以下4个具体的UOW类型，他们都继承自UnitOfWorkBase。Entity Framework, Nhibernate UnitOfWork是实现事务控制的UOW。MongoDB 和 MemoryDB UnitOfWork是没有事务控制的。原因很简单，MongoDB本身就没有完整的事务控制功能，而ABP 框架实现的MemoryDB也是没有事务控制功能的。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230736792-1512699232.png" alt="">
 
IUnitOfWorkManager/UnitOfWorkManager：和其他***manager类一样是一个Facade，他对外提供UOW的功能(用于创建UnitOfWork，并开启UnitOfWork流程)，对内调用各种UOW功能的各种组件。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230719308-2100453085.png" alt="">
 
UnitOfWork拦截器调用UnitOfWorkManager开启UOW流程的代码。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230819526-790223404.png" alt="">
 
Unit Of Work大致运行流程如下
<ol style="font-family: 微软雅黑; font-size: 11pt; font-style: normal; font-weight: normal; margin-top: 0; margin-bottom: 0; margin-left: 0.375in; unicode-bidi: embed; direction: ltr" type="1">
<li style="margin-top: 0; margin-bottom: 0; vertical-align: middle" value="1">UOW拦截器被注入到需要UOW的类中。</li>
<li style="margin-top: 0; margin-bottom: 0; vertical-align: middle">ABP执行标注了UnitOfWork特性的方法时。UOW拦截器以begin()->realAction()->complete()->dispose()顺序执行，其中realAction是被调用的真实业务操作。 UOW拦截器是通过using这种方式调用IUnitOfWork的某个具体实现，这就确保begin 和 dispose也总是会被执行的。 这里需要注意complete却不一定会被执行，比如在complete方法被调用前方法的执行产生了异常。</li>
<li style="margin-top: 0; margin-bottom: 0; vertical-align: middle">当执行一连串的操作时（A方法->B方法->C方法，假设这三个方法都标注了UnitOfWork特性），ABP在执行A方法前会创建整个过程中唯一的IUnitOfWork对象，该对象会启动.NET事务。在执行到B，C方法只会创建InnerUnitOfWorkCompleteHandle。 InnerUnitOfWorkCompleteHandle与IUnitOfWork对象的差异在于它不会创建真实的事务。但ABP会调用其complete，以告知ABP其对应的方法以成功完成，可以提交事务.</li>
<li style="margin-top: 0; margin-bottom: 0; vertical-align: middle">事务可以回滚的关键关键在于IUnitOfWork对象在被dispose时候会检查complete方法有没有被执行，没有的话就认为这个UOW标注的方法没有顺利完成，从而导致事务的回滚操作。</li>
<li style="margin-top: 0; margin-bottom: 0; vertical-align: middle">整个事务的提交是通过第一个UOW（也是唯一个）的complete方法执行时提交的。</li>

</ol>
 
 
InnerUnitOfWorkCompleteHandle关于检查complete方法有没有被执行的代码
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230745214-1732044615.png" alt="">
 
UnitOfWorkManager的beign方法。这边可以看出只有一个IUnitOfWork对象会被创建, 而且由于这个对象是通过容器直接resolve的，那么ABP怎么知道该通过resolve得到什么样的实例呢？是EfUnitOfWork?还是MongoDbUnitOfWork？还是MemoryDbUnitOfWork？还是NhUnitOfWork？答案是ABP不知道，ABP作者假设你只会用其中一个模块，所以如果你把这四个module都加入到你的项目中，结果是不可预知的。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230754448-1522466842.png" alt="">
 
EfUnitOfWork在begin方法中创建.NET事务
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230828761-216746129.png" alt="">
 
EfUnitOfWork提交事务
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230838104-423150805.png" alt="">
 
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230844979-1147771847.png" alt="">
 
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230858042-2140225455.png" alt="">
 
 
CallContextCurrentUnitOfWorkProvider
CallContextCurrentUnitOfWorkProvider的主要功能其实只有一个：通过current返回当前UOW环境下的UOW实例。
一般思路是：将IUnitOfWork对象定义为实例变量或者是类变量。 但是两者事实上都不可行。
如果定义为类变量，那就会面临线程安全的问题，解决方式无非加锁，但会导致并发能力下降，ABP是web框架，因为锁导致并发能力下降是不能接受的。
如果定义为实例变量，在同一线程其他地方resolve CallContextCurrentUnitOfWorkProvider这个实例的时候都会得到一个新的实例，新的实例下current自然是NULL.
ABP的做法是：线程逻辑上下文+线程安全的Dictinoray容器。
线程逻辑上下文用于存储UOW实例的key, 而线程逻辑上下文对于本线程是全局可访问的，而同时具有天然的隔离性。这就确保了当前线程的各个地方都可以得到current的UOW的key
线程安全的Dictinoray容器是一个类实例，用于存放UOW的实例，通过UOW的key就可以取到UOW的实例。
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230802854-1843719156.png" alt="">
 
<img src="https://images2015.cnblogs.com/blog/4776/201603/4776-20160322230811448-1456711029.png" alt="">
 
返回ABP源码分析系列文章目录
 
 
 
  
来源：https://www.cnblogs.com/1zhk/p/5309043.html

頁: [1]

琼殿技术论坛's Archiver

ABP源码分析十：Unit Of Work