内容简介:【编者的话】在上一篇《在上一篇中,已经为大家提供了一个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应用落地了呢。( ̄︶ ̄)↗醒醒!少年。)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Data Structures and Algorithms
Alfred V. Aho、Jeffrey D. Ullman、John E. Hopcroft / Addison Wesley / 1983-1-11 / USD 74.20
The authors' treatment of data structures in Data Structures and Algorithms is unified by an informal notion of "abstract data types," allowing readers to compare different implementations of the same......一起来看看 《Data Structures and Algorithms》 这本书的介绍吧!