内容简介:【编者的话】在上一篇《在上一篇中,已经为大家提供了一个GitHub的Demo。如果已经下载过该Demo的同学,您现在直接进行Pull就可以获得最新的版本了;如果还没有下载该Demo的同学也可以戳下方的跳转链接获取。
【编者的话】在上一篇《 如何运用DDD(五):仓储 》的文章中,我们讲述了有关仓储的概念和使用规范。仓储为聚合提供了持久化到本地的功能,但是在持久化的过程中,有时一个聚合根中的各个领域对象会分散到不同的数据库表里面;又或者是一个用例操作需要操作多个仓储;而这些操作都应该要么同时成功,要么同时失败,因此就需要为这一系列操作提供事务的支持,而事务管理就是由工作单元来提供的。在上一篇中,可能已经提到了工作单元,但是仅仅是一笔带过,现在我们就来详细的探究该如何更好的来实现工作单元。(文章的代码片段都使用的是C#,案例项目也是基于DotNet Core平台)。
直接看东西
在上一篇中,已经为大家提供了一个GitHub的Demo。如果已经下载过该Demo的同学,您现在直接进行Pull就可以获得最新的版本了;如果还没有下载该Demo的同学也可以戳下方的跳转链接获取。
在这里我们可以先来看一下,该项目的应用代码是什么样子:
[HttpPost] public ActionResult<string> Add() { //使用仓储来处理聚合 _itineraryRepository.Add( new Itinerary( "奥特曼", "赛文奥特曼", "杰克奥特曼", "佐菲奥特曼", "泰罗奥特曼")); _itineraryRepository.Add( new Itinerary( "盖亚奥特曼", "戴拿奥特曼", "阿古茹奥特曼", "迪迦奥特曼", "")); return "success"; } [HttpGet] public ActionResult<long> Get() { var count = _itineraryRepository.GetCount(); return count; }
这是在Aspnet Core的Controller中的代码,也就是对外提供的API。可以看到我们仅仅只是通过仓储的调用就完成了所有的操作。(PS:原谅我该演示API没有遵循RESTful风格( ̄▽ ̄)",还有就是那些奥特曼……)。
您可能会说,这里没有做操作,那肯定是在ItineraryRepository里面做了手脚。好吧,下面我们来看看该仓储的实现。
public class ItineraryRepository : EFRepository<UowAppDbContext, Itinerary, Guid> { public void Add(Itinerary itinerary) => DbContext.Set<Itinerary>().Add(itinerary); }
是的,它也只有这么一点点代码。而作为后期的业务扩展和维护,我们只需要完善我们的Itinerary聚合(为它扩展行为和增加实体或值对象)以及ItineraryRepository仓储(为它添加对外检索意图的方法)就可以了。
这种做法的好处可能您很快就能发现:在我们代码中处处都是关于领域对象的操作,尽可能的避免其它基础构建或功能支持组件来干扰程序。除了代码量的减少之外,它也让可读性有着明显的提高,如果在此基础上能够构建出明确而干净的聚合根,那么您的程序将具备更高的可扩展性。
好吧,回到我们今天的主题:工作单元。其实上面的代码就是对仓储中工作单元的巧妙运用,它其实在后面默默的支持着程序的正常运转,这是在调用层面上我们完全感觉不到它的存在而已。下面就为您介绍它是怎么工作和实现的。
什么是工作单元
按照国际管理呢,这一章节都是解读有关原著《 领域驱动设计:软件核心复杂性应对之道 》 中的解释。但是!有关工作单元的概念在书里并没有被明确的提及到。所以为了证明我们确确实实是在前人的基础理念上来实践,而不是胡编乱造自己随便弄了一个概念出来。我特地去找了另外一本较为权威的领域驱动设计教材:《 领域驱动 设计模式 、原理与实践 》 。在该书中对工作单元的解释如下:
事务管理主要与应用程序服务层有关。存储库只与使用聚合根的单一集合的管理有关,而业务用例可能会造成对多个类型聚合的更新。事务管理是由工作单元处理的。工作单元模式的作用是保持追踪业务任务期间聚合的所有变化。一旦所有的变化都已发生,则之后工作单元会协调事务中持久化存储的更新。如果在将变更提交到数据存储的中途出现了问题,那么要确保不损坏数据完整性的话,就要回滚所有的变更以确保数据保持有效的状态。
其实上文的话真的很好理解(相对于原著而言( ̄y▽, ̄)╭ )。首先我们可以得到的第一个结论:事务管理其实是应用服务层干的事。第二个结论:事务的协调管理都是由工作单元来负责的
所以,我们千万不能因为工作单元和仓储有联系就将它放置在领域层里面:事务的提供往往是由数据库管理程序来提供的,而这一类组件我们一般将它们放置在基础构架层,而领域层可以依赖于基础构架层,所以千万要注意,保持您的领域层足够干净,不要让其它的东西干扰它,也更不要将事务处理这类东西放到了您的领域层来。(这一点,您会在后期MiCake<米蛋糕>的使用中看到详细的案例)。
如何实现工作单元
实现工作单元,就是要实现仓储中的事务操作。您可能已经看到过有些实现Repository的框架,它的写法是注入一个unitOfWork,然后从uow中提取一个仓储,然后再用仓储来完成聚合根的持久化操作。类似的代码就像这样:
var yourRepository = uow.GetRepository<yourRepository>(); yourRepository.Add(yourEntity); uow.Commit();
这样做没有一点点的问题,而且是对工作单元和仓储模式的完美实现。uow工作单元中维持了一个事务,从该工作单元中创建的每一个仓储都可以获得该事务,仓储完成了自己的操作之后,工作单元使用Commit方法告诉事务管理器,该事务完成。
夏目去参加了妖怪的聚会,一回到家,猫咪老师就发现了它沾染了妖怪的味道。
当仓储的操作沾染上了工作单元的事务,它也就受到了事务的管理。
如果您喜欢这种实现模式,可以参考 threenine的Threenine.Data项目 。
懒的模式
其实在刚开始,为MiCake(米蛋糕)选取工作单元实现方案的时候,我也打算采用这种方式。但是在思考了一天之后,我还是放弃了。因为我发现这种模式在完成每一次仓储操作的时候,必须要从工作单元中去获取。在Aspnet Core中,不得不在Controller中注入工作单元对象,然后再从该对象里面去获取仓储。这显然削弱了依赖注入所为我们提供的依赖阅读性(原本在构造函数中,我能看出我需要注入的是A仓储,但是现在我看到的只有工作单元)。
其实最重要的一点就是:我太懒啦 o_o ....。 为什么每次都要去多写一个uow.GetXXXXX()。每使用一个仓储就要多写一次获取语句,我就不能好好的只使用仓储吗? 所以在这个想法的强烈刺激下,我选取了另外的实现方法。
接下来,就让我们来实现最开始演示代码中的工作单元吧。哦,对了,忘记说了,无论是演示的Github Demo还是本次的博文,我们都选取了Entity Framework Core来作为数据持久组件。所以有些小伙伴会说,那我使用Dapper或者原生的ADO怎么办? 其实思路都是一样的,您也可以在看了EFCore的版本后,自己写出对应的工作单元版本。如果有机会的话,欢迎在Github的Demo上直接添加,就可以提交供更多的同学参考啦。
实现思路
- 找出当前数据库持久组件中具有事务特征的对象(比如在EF中就是DbContext)
- 创建一个容器去容纳这些对象
- 工作单元就是该容器的实现,它掌管了这些事务对象,并对外公布了提交事务的方法
- 工作单元管理器负责了对工作单元的创建工作
脑袋里有了这些还比较模糊的交互对象之后,我们可以来想一下一个仓储完成添加聚合根的操作是怎么样的:
- 在访问该API之前:使用工作单元管理器创建一个工作单元
- 访问API中的仓储时候:构造一个事务特征对象,并开启一个事务
- 事务开启完成之后:将该事务特征对象尝试放入到当前工作单元
- 仓储事务操作完成后:调用工作单元的提交方法,完成事务的提交,保证仓储的数据一致。
- 事务完成后:释放上面的各个对象
虽然步骤好像有5步,但总结下来,就是将具有事务的对象放置到工作单元中,让它去负责提交。对!就是这么简单,该方法与上面那种从工作单元中获取仓储的方法想法,它是往工作单元中提交。所以,我们此时可以构造出一个伪代码出来,大致理解它的实现:
//1、使用工作单元管理器创建一个工作单元 using (var uow = unitOfWorkManager.Create()) { //2、构造事务特征对象,开启事务并注册到工作单元 RegisteTransactonFeature(DbContext); //3、执行仓储中的内容 DbContext.Set<Itinerary>().Add(itinerary) //4、工作单元保存提交 uow.SaveChanges(); //5、dispose }
至少到目前,我们可以抽象出上面的各个对象了。
您也可以先自己尝试着想一想,每个对象接口应该实现什么功能(方法)。
//首先是事务特征对象,它提供了事务的基本Commit和Rollback方法 public interface ITransactionFeature { public bool IsCommit { get; } public bool IsRollback { get; } void Commit(); Task CommitAsync(CancellationToken cancellationToken = default); void Rollback(); Task RollbackAsync(CancellationToken cancellationToken = default); } //然后是事务特征容器,它具有增加删除事务特征对象的方法 public interface ITransactionFeatureContainer { void RegisteTranasctionFeature(string key, ITransactionFeature TransactionFeature); ITransactionFeature GetOrAddTransactionFeature(string key, ITransactionFeature TransactionFeature); ITransactionFeature GetTransactionFeature(string key); void RemoveTransaction(string key); } //接下来是工作单元,它实现了事务特征容器,并且对外提供提交的方法 public interface IUnitOfWork : ITransactionFeatureContainer { Guid ID { get; } bool IsDisposed { get; } void SaveChanges(); Task SaveChangesAsync(CancellationToken cancellationToken = default); void Rollback(); Task RollbackAsync(CancellationToken cancellationToken = default); } //最后是工作单元管理器,它提供了创建工作单元的方法 public interface IUnitOfWorkManager : IUnitOfWokrProvider, IDisposable { IUnitOfWork Create(); }
落地代码
在构建出接口之后,我们就可以写出具体的实现类了。首先是实现工作单元(UnitOfWork)对象。(由于具体代码实现较多,讲解部分只选取了核心部分,完整代码可以参考Github的项目)
public class UnitOfWork : IUnitOfWork { private readonly Dictionary<string, ITransactionFeature> _transactionFeatures; public UnitOfWork() { _transactionFeatures = new Dictionary<string, ITransactionFeature>(); } //往容器中添加事物特征对象 public virtual ITransactionFeature GetOrAddTransactionFeature( [NotNull]string key, [NotNull] ITransactionFeature transcationFeature) { if (_transactionFeatures.ContainsKey(key)) return _transactionFeatures.GetValueOrDefault(key); _transactionFeatures.Add(key, transcationFeature); return transcationFeature; } //对外提供的保存方法,执行该方法时调用容器内所有事物特征对象的Commit方法 public virtual void SaveChanges() { foreach (var transactionFeature in _transactionFeatures.Values) { transactionFeature.Commit(); } } }
接下来就是与ORM框架关联最深的事务特征对象的实现了,由于我们选取了EF,所以此处应该实现EF版本的事务特征对象:
public class EFTransactionFeature : ITransactionFeature { private IDbContextTransaction _dbContextTransaction; private DbContext _dbContext; public EFTransactionFeature(DbContext dbContext) { _dbContext = dbContext; } //设置事务 public void SetTransaction(IDbContextTransaction dbContextTransaction) { _isOpenTransaction = true; _dbContextTransaction = dbContextTransaction; } public void Commit() { if (IsCommit) return; IsCommit = true; //EF 事务的提交 _dbContext.SaveChanges(); _dbContextTransaction?.Commit(); } }
建立好了这两个对象之后,其实我们只需要一个流转过程就可以实现工作单元了。这个流程就是将事务特征对象添加到工作单元中,但是我们应该在什么时候将它添加进去呢?看过第一版GitHub代码的小伙伴可能知道,在仓储调用的时候就可以完成该操作。当时在第一版中,我们的实现代码是这样的:
public class EFRepository { protected IUnitOfWorkManager UnitOfWorkManager { get; private set; } protected DbContext DbContext { get; private set; } public EFRepository(IUnitOfWorkManager unitOfWorkManager, DbContext dbContext) { UnitOfWorkManager = unitOfWorkManager; DbContext = dbContext; } public void Add(TAggregateRoot aggregateRoot) { RegistUnitOfWork(DbContext); DbContext.Set<TAggregateRoot>().Add(aggregateRoot); } private void RegistUnitOfWork(DbContext dbContext) { string key = $"EFTransactionFeature - {dbContext.ContextId.InstanceId.ToString()}"; unitOfWork.ResigtedTransactionFeature(key, new EFTransactionFeature(DbContext)); } }
在每一次进行仓储操作的时候,都调用了一个RegistUnitOfWork的方法,来完成事务特征对象和工作单元的流转工作。但是很快您就能发现问题:EFRepository是我们实现的一个基类,以后所有的仓储操作都继承该类来完成操作,那不是每扩展一个方法,我都要在该方法中写一句注册代码?如果我忘记写了怎么办。还有一点,该注册过程并没有开启一个事务,那么事务是怎么来的呢?
那么怎么才能避免用户每一次都要去显示调用注册呢,而是让用户在不知不觉中就完成了该操作。所以我们得思考在每一个方法中,用户都一定会写的代码是什么,然后在该代码上下手。可能您已经想到了,DbContext!是的,每一个方法里,用户都会去写DbContext,所以我们可以在他获取DbContext的时候就完成注册操作。所以,优化后的代码就是这样的:
public class EFRepository { public virtual TDbContext DbContext { get => _dbContextFactory.CreateDbContext(); } public void Add(TAggregateRoot aggregateRoot) { DbContext.Set<TAggregateRoot>().Add(aggregateRoot); } }
而该_dbContextFactory的实现就更简单了,他要完成的任务就是注册到工作单元并且开启事务。
internal class UowDbContextFactory<TDbContext> { private readonly IUnitOfWorkManager _uowManager; public UowDbContextFactory(IUnitOfWorkManager uowManager) { _uowManager = uowManager; } public TDbContext CreateDbContext() { AddDbTransactionFeatureToUow(currentUow, DbContext); return wantedDbContext; } private void AddDbTransactionFeatureToUow(IUnitOfWork uow, TDbContext dbContext) { string key = $"EFCore - {dbContext.ContextId.InstanceId.ToString()}"; var efFeature = uow.GetOrAddTransactionFeature(key, new EFTransactionFeature(dbContext)); if (IsFeatureNeedOpenTransaction(uow, efFeature)) { var dbcontextTransaction = dbContext.Database.BeginTransaction(); efFeature.SetTransaction(dbcontextTransaction); } } private bool IsFeatureNeedOpenTransaction(IUnitOfWork uow, EFTransactionFeature efFeature) { return !efFeature.IsOpenTransaction; } }
dbContext.Database.BeginTransaction是EF为我们提供的手动开启事务的方法。如果您尝试实现另外ORM版本的工作单元,想一下在该ORM中是怎么开启的事务。
此时,我们就已经实现了工作单元的流转了,那么还有一个问题就是:我们怎么默认去实现一个工作单元,而不是每一次都需要手动去开启并提交。
AspNet Core为我们提供了很好的拦截方法。第一种方法: 我们可以在中间件中完成,因为所有的请求都要穿过中间件,我们可以在方法到API之前就开启事务,等API访问结束后就提交事务。第二种方法: 通过IActionFilter等周期接口来完成。本案例选取了第一种实现方法,您也可以根据您自己的爱好选取自己的实现方式。
缺陷
到这里我们已经实现了像上面Demo版本的工作单元,但是该工作单元其实还有许多特性没有实现:
- 一个业务操作(一个API)中没有创建多个工作单元的能力
- 目前事务的操作来源于EF Core的支持,如果项目存在多种数据访问方式(比如一个EF,一个ADO),它们之间如何依靠工作单元来完成事务
- 没有识别什么时候需要开启工作单元,如果一个操作仅仅需要获取数据,其实我们是不需要开启工作单元的
不过如果您的项目仅仅使用了一种ORM框架并且只需要开启一个工作单元,那么可以尝试使用该实现。
在实现MiCake真正的工作单元中,我尝试了很多方法来解决上面的问题。在后面的文章中,您也会看到MiCake真正的工作单元。
附上一个当时写工作单元的手记( ̄︶ ̄)↗
总结
本来这篇文章不打算写在《如何运用领域驱动设计》这个系列的,但是后来纠结了一下,还是纳入了该系列。由于该篇文章是实现工作单元的,所以代码量就比较大,希望不会给您造成阅读上的困难。下一篇的文章,是一个谈了很久的问题——持久化值对象,现在终于是时候该解决它了。在本次Demo中您看到的聚合根Itinerary所有的属性都是string,很显然这是不符合常理的,所以在下一次就要让它成为真正的领域对象。(PS:改成真正的领域对象后,感觉都可以单体DDD应用落地了呢。( ̄︶ ̄)↗醒醒!少年。)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
程式之美-微軟技術面試心得
編程之美小 / 悅知文化 / 2008.06.20 / 490元
書內容分為以下幾個部分: ▓ 遊戲之樂:從遊戲和其他有趣問題出發,化繁為簡,分析總結。 ▓ 數字之魅:程式設計的過程實際上就是和數字及字元打交道的過程。這一部分收集了一些這方面的有趣探討。 ▓ 結構之法:彙集了常見的對字串、鏈表、佇列,以及樹進行操作的題目。 ▓ 數學之趣:列舉了一些不需要寫具體程式的數學問題,鍛煉讀者的抽象思考能力。 ▓ 書中絕大部分題目都提供了詳細......一起来看看 《程式之美-微軟技術面試心得》 这本书的介绍吧!