.NET領域驅動設計實戰系列專題四：前期準備之工作單元模式(Unit Of Work) · Learning Hard C# 博客原文

# [.NET領域驅動設計實戰系列]專題四：前期準備之工作單元模式(Unit Of Work) ## 一、前言在前一專題中介紹了規約模式的實現，然后在倉儲實現中，經常會涉及工作單元模式的實現。然而，在我的網上書店案例中也將引入工作單元模式，所以本專題將詳細介紹下該模式，為后面案例的實現做一個鋪墊。 ## 二、什么是工作單元模式（Unit Of Work）工作單元模式：用來維護一個已經被業務事務修改（包括添加、修改或更新）的業務對象列表。工作單元模式復制協調這些修改的持久化工作以及所有標記的并發問題。采用工作單元模式帶來的好處是能夠保證數據的完整性。如果在持久化一系列業務對象的過程中出現問題，則將所有的修改回滾，以保證數據始終處于有效狀態。簡單來說，工作單元模式就是把業務對象的持久化由工作單元實現類進行統一管理。而不想之前那樣，分布在每個具體的倉儲類中，這樣就可以達到一系列業務對象的統一管理，不至于在每個業務對象中出現統一的提交和回滾業務邏輯，實現代碼最大化重用。 ## 三、工作單元模式的實現從工作單元模式的定義可以看出，工作單元需要保存被業務事務修改的業務對象列表，則必須定義3個集合，分別是添加、修改和更新集合，然而如果使用EF的話，則不需要了，因為DbContext.DbSet<T>就可以代替這三個集合。這里為了演示，我們并沒有引入EF，所以我們實現中定義了3個集合來保存被修改的業務對象。既然要在工作單元類中進行統一管理，則我們就需要在工作單元類中定義一個Commit方法，該方法的實現就是去遍歷這三個集合的對象，對它們進行統一提交，如果其中一個失敗，則進行數據回滾。根據面向接口編程原則，我們需要定義一個工作單元接口，即IUnitOfWork接口。經過上面的分析，再結合下面具體的實現來理解，工作單元模式的實現也就更加清晰了，下面讓我們一起去實現下工作單元模式。 **第一步：我們需要定義我們的領域層。** 這里以銀行賬號之間轉賬業務作為背景，自然涉及到銀行賬號業務對象。并且領域層同時包括倉儲接口的定義和領域服務。領域服務指的是：如果有些方法涉及多個實體或聚合的交互，此時就應該把這段邏輯放到領域服務中，領域服務只有方法沒有屬性，也就是沒有狀態的。在銀行轉賬業務中，賬戶之間的轉賬操作就適合作為領域服務來提供，因為轉賬操作涉及多個聚合間的交互，需要從一個賬戶扣錢和另一個賬戶加錢。所以在領域層還需要定義賬戶轉賬服務。經過這樣的分析，則領域層的實現如下所示： ``` // 賬號倉儲接口 public interface IAccountRepository { void Save(Account account); void Add(Account account); void Remove(Account account); } // 賬號實體類 public class Account : IAggregateRoot { public decimal Balance { get; set; } public System.Guid Id { get; set; } public Account() { Id = Guid.NewGuid(); } } // 賬號轉賬領域服務類 public class AccountService { private readonly IAccountRepository _productRepository; private readonly IUnitOfWork _unitOfWork; public AccountService(IAccountRepository productRepository, IUnitOfWork unitOfWork) { _productRepository = productRepository; _unitOfWork = unitOfWork; } public void Transfer(Account from, Account to, decimal amount) { if (from.Balance >= amount) { from.Balance -= amount; to.Balance += amount; _productRepository.Save(from); _productRepository.Save(to); _unitOfWork.Commit(); } } } ``` 　**　第二步：構建基礎設施層** 我們一般把工作單元模式的實現放在基礎設施層，因為工作單元模式屬于一種技術支持。根據上面工作單元模式的分析，我們首先定義IUnitOfWork接口，接著定義它的實現。因為這里沒有引入EF，所以具體的實體的持久化還是調用具體的倉儲來實現持久化的，所以還需要定義一個IUnitOfWorkRepository接口。則基礎設施層的實現如下所示： ``` // 工作單元接口 public interface IUnitOfWork { void RegisterAmended(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository); void RegisterNew(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository); void RegisterRemoved(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository); void Commit(); } // 工作單元實現 public class UnitOfWork : IUnitOfWork { // 引入了EF就不需要額外定義三個列表了，因為EF框架中包含的DbContext.DbSet<T>可以記錄這3個列表 // 然而在ByteartRetail案例中，也定義這3個列表，但其沒有被真真使用到 private readonly Dictionary<IAggregateRoot, IUnitOfWorkRepository> _addedEntities; private readonly Dictionary<IAggregateRoot, IUnitOfWorkRepository> _changedEntities; private readonly Dictionary<IAggregateRoot, IUnitOfWorkRepository> _deletedEntities; public UnitOfWork() { _addedEntities = new Dictionary<IAggregateRoot, IUnitOfWorkRepository>(); _changedEntities = new Dictionary<IAggregateRoot, IUnitOfWorkRepository>(); _deletedEntities = new Dictionary<IAggregateRoot, IUnitOfWorkRepository>(); } // 將業務對象實體添加到內部列表中，真正完成實體持久化操作的還是由具體的倉儲類去完成 public void RegisterAmended(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository) { if (!_changedEntities.ContainsKey(entity)) { _changedEntities.Add(entity, unitofWorkRepository); } } public void RegisterNew(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository) { if (!_addedEntities.ContainsKey(entity)) { _addedEntities.Add(entity, unitofWorkRepository); }; } public void RegisterRemoved(IAggregateRoot entity, IUnitOfWorkRepository unitofWorkRepository) { if (!_deletedEntities.ContainsKey(entity)) { _deletedEntities.Add(entity, unitofWorkRepository); } } protected void ClearRegisterations() { _addedEntities.Clear(); _changedEntities.Clear(); _deletedEntities.Clear(); } // 對內部列表進行統一提交 // 引入EF后，提交的實現有點不同，它具體的持久化只需要調用DbContext.SaveChanges方法來完成 // 則具體的倉儲接口不需要實現IUnitOfWorkRepository接口，則自然不存在IUnitOfWorkRepository接口的定義 public void Commit() { // 事務范圍 using (var scope = new TransactionScope()) { // 分別調用具體的倉儲對象的持久化邏輯來對業務對象進行持久化 foreach (var entity in this._addedEntities.Keys) { this._addedEntities[entity].PersistCreationOf(entity); } foreach (var entity in this._changedEntities.Keys) { this._changedEntities[entity].PersistUpdateOf(entity); } foreach (var entity in this._deletedEntities.Keys) { this._deletedEntities[entity].PersistDeletionOf(entity); } scope.Complete(); } // 清楚內存中對象 ClearRegisterations(); } } public interface IUnitOfWorkRepository { Hashtable AccountList { get; } void PersistCreationOf(IAggregateRoot entity); void PersistUpdateOf(IAggregateRoot entity); void PersistDeletionOf(IAggregateRoot entity); } public interface IAggregateRoot { Guid Id { get; } } ``` **第三步：實現倉儲層。** 倉儲的實現在之前也說過，它其實可以放在基礎設施層里，但一般總將其放在一個單獨層進行實現。所以這里也就放在一個單獨層進行實現。這里倉儲實現只有一個類，即對IAccountRepository接口的實現。具體的實現代碼如下所示： ``` public class AccountRepository : IAccountRepository, IUnitOfWorkRepository { private readonly IUnitOfWork _unitOfWork; public AccountRepository(IUnitOfWork unitOfWork) { _unitOfWork = unitOfWork; AccountList = new Hashtable(); } public Hashtable AccountList { get; set; } #region IAccountRepository Members public void Save(Account account) { _unitOfWork.RegisterAmended(account, this); } public void Add(Account account) { _unitOfWork.RegisterNew(account, this); } public void Remove(Account account) { _unitOfWork.RegisterRemoved(account, this); } #endregion #region IUnitOfWorkRepository Members public void PersistUpdateOf(IAggregateRoot entity) { // ADO.net code to update the entity... // 這里為了演示，只它持久化到內存中 if (AccountList.ContainsKey(entity.Id)) { AccountList[entity.Id] = entity; } } public void PersistCreationOf(IAggregateRoot entity) { // ADO.net code to Add the entity... // 這里為了演示，只它持久化到內存中 AccountList.Add(entity.Id, entity); } public void PersistDeletionOf(IAggregateRoot entity) { // ADO.net code to delete the entity... // 這里為了演示，只它持久化到內存中 if (AccountList.ContainsKey(entity.Id)) { AccountList.Remove(entity.Id); } } #endregion } ``` 這樣，就完成了工作單元模式模式的實現和應用了，工作單元模式的實現存在于基礎設施層，其他層的構建主要為了演示，下面通過一個測試項目來進行測試下工作單元的使用。具體項目的引入將會在下一個專題中介紹，下一個專題將引入工作單元模式和規約模式的實現。具體的測試項目的代碼如下所示： ``` [TestClass] public class AccountRepositoryTests { [TestMethod] public void AccountRepository_Delegates_Changes_To_The_Unit_Of_Work_Instance() { var accountToBeAmended = new Account(); var accountToBeRemoved = new Account(); var accountToBeAdded = new Account(); // 需要引入Moq Mock框架 var unitOfWorkMockery = new Mock<IUnitOfWork>(); var accountRepository = new AccountRepository(unitOfWorkMockery.Object); unitOfWorkMockery.Setup(uow => uow.RegisterAmended(accountToBeAmended, accountRepository)); unitOfWorkMockery.Setup(uow => uow.RegisterNew(accountToBeAdded, accountRepository)); unitOfWorkMockery.Setup(uow => uow.RegisterRemoved(accountToBeRemoved, accountRepository)); accountRepository.Add(accountToBeAdded); accountRepository.Save(accountToBeAmended); accountRepository.Remove(accountToBeRemoved); unitOfWorkMockery.VerifyAll(); } } ``` ## 四、總結到這里，本專題的內容就介紹完了，上一專題和這一專題都是一個前期準備的專題，主要是為網上書店案例引入這2個模式的實現做一個鋪墊，為了讓大家對知識點分開吸收，然后再通過后面一專題的應用來加深理解這2個模式的應用。本專題的所有源碼下載：[UnitOfWorkDemo.zip](http://files.cnblogs.com/files/zhili/UnitOfWorkDemo.zip)