ABP以AOP的方式實現UnitOfWork功能。通過UnitOfWorkRegistrar將UnitOfWorkInterceptor在某個類被註冊到IOCContainner的時候，一併新增到該類在容器中對應的ComponentModel的Interceptors集合中。總結一句話就是，UOW的功能是通過自定義Castle攔截器來實現的。本文主要介紹ABP核心框架中的UnitOfWork的實現，後續會分別介紹ABP其他模組是如何具體實現IUnitOfWork的

如圖，AbpKernelModule呼叫UnitOfWorkRegister的Initialize方法將UnitOfWorkInterceptor攔截器新增到標註了UnitOfWork特性方

下圖是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

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大致執行流程如下

1. UOW攔截器被注入到需要UOW的類中。
2. ABP執行標註了UnitOfWork特性的方法時。UOW攔截器以begin()->realAction()->complete()->dispose()順序執行，其中realAction是被呼叫的真實業務操作。 UOW攔截器是通過using這種方式呼叫IUnitOfWork的某個具體實現，這就確保begin 和 dispose也總是會被執行的。 這裡需要注意complete卻不一定會被執行，比如在complete方法被呼叫前方法的執行產生了異常。
3. 當執行一連串的操作時（A方法->B方法->C方法，假設這三個方法都標註了UnitOfWork特性），ABP在執行A方法前會建立整個過程中唯一的IUnitOfWork物件，該物件會啟動.NET事務。在執行到B，C方法只會建立InnerUnitOfWorkCompleteHandle。 InnerUnitOfWorkCompleteHandle與IUnitOfWork物件的差異在於它不會建立真實的事務。但ABP會呼叫其complete，以告知ABP其對應的方法以成功完成，可以提交事務.
4. 事務可以回滾的關鍵關鍵在於IUnitOfWork物件在被dispose時候會檢查complete方法有沒有被執行，沒有的話就認為這個UOW標註的方法沒有順利完成，從而導致事務的回滾操作。
5. 整個事務的提交是通過第一個UOW（也是唯一個）的complete方法執行時提交的。

InnerUnitOfWorkCompleteHandle關於檢查complete方法有沒有被執行的程式碼

UnitOfWorkManager的beign方法。這邊可以看出只有一個IUnitOfWork物件會被建立, 而且由於這個物件是通過容器直接resolve的，那麼ABP怎麼知道該通過resolve得到什麼樣的例項呢？是EfUnitOfWork?還是MongoDbUnitOfWork？還是MemoryDbUnitOfWork？還是NhUnitOfWork？答案是ABP不知道，ABP作者假設你只會用其中一個模組，所以如果你把這四個module都加入到你的專案中，結果是不可預知的。

EfUnitOfWork在begin方法中建立.NET事務

EfUnitOfWork提交事務

CallContextCurrentUnitOfWorkProvider

CallContextCurrentUnitOfWorkProvider的主要功能其實只有一個：通過current返回當前UOW環境下的UOW例項。

一般思路是：將IUnitOfWork物件定義為例項變數或者是類變數。 但是兩者事實上都不可行。

如果定義為類變數，那就會面臨執行緒安全的問題，解決方式無非加鎖，但會導致併發能力下降，ABP是web框架，因為鎖導致併發能力下降是不能接受的。

如果定義為例項變數，在同一執行緒其他地方resolve CallContextCurrentUnitOfWorkProvider這個例項的時候都會得到一個新的例項，新的例項下current自然是NULL.

ABP的做法是：執行緒邏輯上下文+執行緒安全的Dictinoray容器。

執行緒邏輯上下文用於儲存UOW例項的key, 而執行緒邏輯上下文對於本執行緒是全域性可訪問的，而同時具有天然的隔離性。這就確保了當前執行緒的各個地方都可以得到current的UOW的key

執行緒安全的Dictinoray容器是一個類例項，用於存放UOW的例項，通過UOW的key就可以取到UOW的例項。