ABP源码分析十：Unit Of Work

ABP以AOP的方式实现UnitOfWork功能。通过UnitOfWorkRegistrar将UnitOfWorkInterceptor在某个类被注册到IOCContainner的时候，一并添加到该类在容器中对应的ComponentModel的Interceptors集合中。总结一句话就是，UOW的功能是通过自定义Castle拦截器来实现的。本文主要介绍ABP核心框架中的UnitOfWork的实现，后续会分别介绍ABP其他模块是如何具体实现IUnitOfWork的

如图，AbpKernelModule调用UnitOfWorkRegister的Initialize方法将UnitOfWorkInterceptor拦截器添加到标注了UnitOfWork特性方法的类，以及实现IRepository或IApplicationService的类上。

下图是UnitOfWorkRegister的代码

和通常实现的AOP一样，ABP定义了UnitOfWork特性，方便业务层为方法注入UOW功能。

UnitOfWorkAttribute：用于标注某个方法位UnitOfWork的Attribute类. 通过这个特性，可以指定是否启用UOW，事务隔离级别，TransactionScopeOption等

UnitOfWorkOptions：封装了UnitOfWork参数的类，其实例是通过UnitOfWorkAttribute的CreateOptions来生成的。

接下来，分析下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抽象类实现的。

ABP中共有以下4个具体的UOW类型，他们都继承自UnitOfWorkBase。Entity Framework, Nhibernate UnitOfWork是实现事务控制的UOW。MongoDB 和 MemoryDB UnitOfWork是没有事务控制的。原因很简单，MongoDB本身就没有完整的事务控制功能，而ABP 框架实现的MemoryDB也是没有事务控制功能的。

IUnitOfWorkManager/UnitOfWorkManager：和其他***manager类一样是一个Facade，他对外提供UOW的功能(用于创建UnitOfWork，并开启UnitOfWork流程)，对内调用各种UOW功能的各种组件。

UnitOfWork拦截器调用UnitOfWorkManager开启UOW流程的代码。

Unit Of Work大致运行流程如下

UOW拦截器被注入到需要UOW的类中。
ABP执行标注了UnitOfWork特性的方法时。UOW拦截器以begin()->realAction()->complete()->dispose()顺序执行，其中realAction是被调用的真实业务操作。 UOW拦截器是通过using这种方式调用IUnitOfWork的某个具体实现，这就确保begin 和 dispose也总是会被执行的。这里需要注意complete却不一定会被执行，比如在complete方法被调用前方法的执行产生了异常。
当执行一连串的操作时（A方法->B方法->C方法，假设这三个方法都标注了UnitOfWork特性），ABP在执行A方法前会创建整个过程中唯一的IUnitOfWork对象，该对象会启动.NET事务。在执行到B，C方法只会创建InnerUnitOfWorkCompleteHandle。 InnerUnitOfWorkCompleteHandle与IUnitOfWork对象的差异在于它不会创建真实的事务。但ABP会调用其complete，以告知ABP其对应的方法以成功完成，可以提交事务.
事务可以回滚的关键关键在于IUnitOfWork对象在被dispose时候会检查complete方法有没有被执行，没有的话就认为这个UOW标注的方法没有顺利完成，从而导致事务的回滚操作。
整个事务的提交是通过第一个UOW（也是唯一个）的complete方法执行时提交的。

InnerUnitOfWorkCompleteHandle关于检查complete方法有没有被执行的代码

UnitOfWorkManager的beign方法。这边可以看出只有一个IUnitOfWork对象会被创建, 而且由于这个对象是通过容器直接resolve的，那么ABP怎么知道该通过resolve得到什么样的实例呢？是EfUnitOfWork?还是MongoDbUnitOfWork？还是MemoryDbUnitOfWork？还是NhUnitOfWork？答案是ABP不知道，ABP作者假设你只会用其中一个模块，所以如果你把这四个module都加入到你的项目中，结果是不可预知的。