从壹开始微服务 [ DDD ] 之十一 ║ 基于源码分析，命令分发的过程（二）

时间  2019-11-05
标签 开始 微服 ddd 之十 基于 源码 分析 命令 分发 过程 栏目 设计模式 繁體版
原文   原文链接

缘起

哈喽小伙伴周三好，老张又来啦，DDD领域驱动设计的第二个D也快说完了，下一个系列我也在考虑之中，是 Id4 仍是 Dockers 尚未想好，甚至昨天我还想，下一步是否是能够写一个简单的Angular 入门教程，原本是想来个先后端分离的教学视频的，简单试了试，发现本身的声音很差听，真心很差听那种，就做罢了，我看博客园有一个大神在 Bilibili 上有一个视频，具体地址忘了，有须要的留言，我找找。不过最近年末了比较累了，目前已经写了15万字了（一百天，平均一天1500字），或者看看是否是给本身放一个假吧，本身也找一些书看一看，给本身充充电，但愿你们多提一下建议或者帮助吧。html

言归正传，在上一篇文章中《之十 ║领域驱动【实战篇·中】：命令总线Bus分发（一）》，我主要是介绍了，若是经过命令模式来对咱们的API层（这里也包括应用层）进行解耦，经过命令分发，能够很好的解决在应用层写大量的业务逻辑，以及多个对象之间混乱的关联的问题。若是对上一篇文章不是很记得了，我这里简单再总结一下，若是你能看懂这些知识点，并内心能大概行程一个轮廓，那能够继续往下看了，若是说看的很陌生，或者想不起来了，那请看上一篇文章吧。上篇文章有如下几个小点：git

一、什么是中介者模式？以及中介者模式的原理？（提示：多对象不依赖，但可通信）github

二、MediatR 是如何实现中介者服务的？经常使用哪两种方法？（提示：请求/响应）后端

三、工做单元是什么？做用？（提示：事务）缓存

 

这些知识点都是在上文中提到的，可能说的有点儿凌乱，不知道是否能看懂，上篇遗留了几个问题，因此我就新开了一篇文章，来重点对上一篇文章进行解释说明，你们能够看看是否和本身想的同样，欢迎来交流。服务器

固然仍是每篇一问，也是本文的提纲：app

一、咱们是如何把一个Command命令，一步步走到持久化的？前后端分离

二、你本身能画一个详细的流程草图么？异步

 

零、今天实现左下角浅紫色的下框部分

 

（昨天的故事中，说到了，我们已经创建了一个基于 MediatR 的在缓存中的命令总线，咱们能够在任何一个地方经过该总线进行命令的分发，而后咱们在应用层 StudentAppService.cs 中，对添加StudentCommand进行了分发，那咱们到底应该如何分发，中介者又是如何调用的呢， 今天咱们就继续接着昨天的故事往下说... ）async

 

1、建立命令处理程序 CommandHandlers

我们先把处理程序作出来，具体是如何执行的，我们下边会再说明。

一、添加一个命令处理程序基类 CommandHandler.cs

namespace Christ3D.Domain.CommandHandlers
{
    /// <summary>
    /// 领域命令处理程序
    /// 用来做为所有处理程序的基类，提供公共方法和接口数据
    /// </summary>
    public class CommandHandler
    {
        // 注入工做单元
        private readonly IUnitOfWork _uow;
        // 注入中介处理接口（目前用不到，在领域事件中用来发布事件）
        private readonly IMediatorHandler _bus;
        // 注入缓存，用来存储错误信息（目前是错误方法，之后用领域通知替换）
        private IMemoryCache _cache;

        /// <summary>
        /// 构造函数注入
        /// </summary>
        /// <param name="uow"></param>
        /// <param name="bus"></param>
        /// <param name="cache"></param>
        public CommandHandler(IUnitOfWork uow, IMediatorHandler bus, IMemoryCache cache)
        {
            _uow = uow;
            _bus = bus;
            _cache = cache;
        }

        //工做单元提交
        //若是有错误，下一步会在这里添加领域通知
        public bool Commit()
        {
            if (_uow.Commit()) return true;

            return false;
        }
    }
}

这个仍是很简单的，只是提供了一个工做单元的提交，下边会增长对领域通知的伪处理。

 

二、定义学生命令处理程序 StudentCommandHandler.cs 

namespace Christ3D.Domain.CommandHandlers
{
    /// <summary>
    /// Student命令处理程序
    /// 用来处理该Student下的全部命令
    /// 注意必需要继承接口IRequestHandler<,>，这样才能实现各个命令的Handle方法
    /// </summary>
    public class StudentCommandHandler : CommandHandler,
        IRequestHandler<RegisterStudentCommand, Unit>,
        IRequestHandler<UpdateStudentCommand, Unit>,
        IRequestHandler<RemoveStudentCommand, Unit>
    {
        // 注入仓储接口
        private readonly IStudentRepository _studentRepository;
        // 注入总线
        private readonly IMediatorHandler Bus;
        private IMemoryCache Cache;

        /// <summary>
        /// 构造函数注入
        /// </summary>
        /// <param name="studentRepository"></param>
        /// <param name="uow"></param>
        /// <param name="bus"></param>
        /// <param name="cache"></param>
        public StudentCommandHandler(IStudentRepository studentRepository,
                                      IUnitOfWork uow,
                                      IMediatorHandler bus,
                                      IMemoryCache cache
                                      ) : base(uow, bus, cache)
        {
            _studentRepository = studentRepository;
            Bus = bus;
            Cache = cache;
        }

        // RegisterStudentCommand命令的处理程序
        // 整个命令处理程序的核心都在这里
        // 不只包括命令验证的收集，持久化，还有领域事件和通知的添加
        public Task<Unit> Handle(RegisterStudentCommand message, CancellationToken cancellationToken)
        {
            // 命令验证
            if (!message.IsValid())
            {
                // 错误信息收集
                NotifyValidationErrors(message);
                return Task.FromResult(new Unit());
            }

            // 实例化领域模型，这里才真正的用到了领域模型
            // 注意这里是经过构造函数方法实现
            var customer = new Student(Guid.NewGuid(), message.Name, message.Email, message.Phone, message.BirthDate);
            
            // 判断邮箱是否存在
            // 这些业务逻辑，固然要在领域层中（领域命令处理程序中）进行处理
            if (_studentRepository.GetByEmail(customer.Email) != null)
            {
                //这里对错误信息进行发布，目前采用缓存形式
                List<string> errorInfo = new List<string>() { "The customer e-mail has already been taken." };
                Cache.Set("ErrorData", errorInfo);
                return Task.FromResult(new Unit());
            }

            // 持久化
            _studentRepository.Add(customer);

            // 统一提交
            if (Commit())
            {
                // 提交成功后，这里须要发布领域事件
                // 好比欢迎用户注册邮件呀，短信呀等

                // waiting....
            }

            return Task.FromResult(new Unit());

        }

        // 同上，UpdateStudentCommand 的处理方法
        public Task<Unit> Handle(UpdateStudentCommand message, CancellationToken cancellationToken)
        {      
             // 省略...
        }

        // 同上，RemoveStudentCommand 的处理方法
        public Task<Unit> Handle(RemoveStudentCommand message, CancellationToken cancellationToken)
        {
            // 省略...
        }

        // 手动回收
        public void Dispose()
        {
            _studentRepository.Dispose();
        }
    }
}

 

三、注入咱们的处理程序

在咱们的IoC项目中，注入咱们的命令处理程序，这个时候，你可能有疑问，为啥是这样的，下边我讲原理的时候会说明。

// Domain - Commands
services.AddScoped<IRequestHandler<RegisterStudentCommand, Unit>, StudentCommandHandler>();
services.AddScoped<IRequestHandler<UpdateStudentCommand, Unit>, StudentCommandHandler>();
services.AddScoped<IRequestHandler<RemoveStudentCommand, Unit>, StudentCommandHandler>();

 

好啦！这个时候咱们已经成功的，顺利的，把由中介总线发出的命令，借助中介者 MediatR ，经过一个个处理程序，把咱们的全部命令模型，领域模型，验证模型，固然还有之后的领域事件，和领域通知联系在一块儿了，只有上边两个类，甚至说只须要一个 StudentCommandHandler.cs 就能搞定，由于另外一个 CommandHandler 仅仅是一个基类，彻底能够合并在 StudentCommandHandler 类里，是否是感受很神奇，若是这个时候你没有感受到他的好处，请先停下往下看的眼睛，仔细思考一下，若是咱们不采用这个方法，咱们会是怎么的工做：

在 API 层的controller中，进行参数验证，而后if else 判断，

接下来在服务器中写持久化，而后也要对持久化中的错误信息，返回到 API 层；

不只如此，咱们还须要提交成功后，进行发邮件，或者发短信等子业务逻辑（固然这一块，我们还没实现，不过已经挖好了坑，下一节会说到。）；

最后，咱们可能之后会说，添加成功和删除成功发的邮件方法不同，甚至还有其余；

如今想一想，若是这样的工做，咱们的业务逻辑须要写在哪里？毫无疑问的，固然是在API层和应用层，咱们领域层都干了什么？只有简单的一个领域模型和仓储接口！那这可真的不是DDD领域驱动设计的第二个D —— 驱动。

可是如今咱们采用中介者模式，用命令驱动的方法，状况就不是这样了，咱们在API 层的controller中，只有一行代码，在应用服务层也只有两行；

 var registerCommand = _mapper.Map<RegisterStudentCommand>(StudentViewModel);
 Bus.SendCommand(registerCommand);

 

到这个时候，咱们已经从根本上，第二次了解了DDD领域驱动设计所带来的不同的快感（第一次是领域、聚合、值对象等相关概念）。固然可能还不是很透彻，至少咱们已经经过第一条总线——命令总线，来实现了复杂多模型直接的通信了，下一篇咱们说领域事件的时候，你会更清晰。那聪明的你必定就会问了：

好吧，你说的这些我懂了，也大概知道了怎么用，那它们是如何运行的呢？不知道过程，反而没法理解其做用！没错，那接下来，咱们就具体说一说这个命令是如何分发的，请耐心往下看。

 

2、基于源码分析命令处理过程

这里说的基于源码，不是一字一句的讲解，那要是我能说出来，我就是做者了😄，我就简单的说一说，但愿你们能看得懂。

0、下载 MediatR 源码

既然要研究源码，这里就要下载相应的代码，这里有两个方式，

一、能够在VS 中下载 ReSharper ，能够查看反编译的全部代码，注意会比之前卡一些。

二、直接查看Github ，https://github.com/jbogard/MediatR/tree/master/src/MediatR，如今开源的项目是愈来愈多，既然人家开源了，我们就不能辜负了他们的开源精神，因此下载下来看一看也是很不错。

原本我想把整个类库，添加到我们的项目中，发现有兼容问题，想一想仍是算了，就把其中几个方法摘出来了，好比这个 Mediator.Send() 方法。

 

 

下边就是总体流程，

一、应用层的命令请求：

// 领域命令请求
Bus.SendCommand(registerCommand);

 

二、领域命令的包装

不知道你们还记得 MediatR 有哪两种经常使用方法，没错，就是请求/响应 Request/Response 和 发布 Publish 这两种，我们的命令是用的第一种方法，因此今天就先说说这个 Mediator.Send() 。我们在中介内存总线InMemoryBus.cs 中，定义了SendCommand方法，是基于IMediator 接口的，今天我们就把真实的方法拿出来：


一、把源代码中 Internal 文件夹下的 RequestHandlerWrapper.cs 放到咱们的基础设施层的 Christ3D.Infra.Bus 层中

从这个名字 RequestHandlerWrapper 中咱们也能看懂，这个类的做用，就是把咱们的请求领域命令，包装成指定的命令处理程序。

 

二、修改咱们的内存总线方法

namespace Christ3D.Infra.Bus
{
    /// <summary>
    /// 一个密封类，实现咱们的中介内存总线
    /// </summary>
    public sealed class InMemoryBus : IMediatorHandler
    {
        //构造函数注入
        private readonly IMediator _mediator;
        //注入服务工厂
        private readonly ServiceFactory _serviceFactory;
        private static readonly ConcurrentDictionary<Type, object> _requestHandlers = new ConcurrentDictionary<Type, object>();

        public InMemoryBus(IMediator mediator, ServiceFactory serviceFactory)
        {
            _mediator = mediator;
            _serviceFactory = serviceFactory;
        }

        /// <summary>
        /// 实现咱们在IMediatorHandler中定义的接口
        /// 没有返回值
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="command"></param>
        /// <returns></returns>
        public Task SendCommand<T>(T command) where T : Command
        {
            //这个是正确的
            //return _mediator.Send(command);//请注意 入参 的类型

            //注意！这个仅仅是用来测试和研究源码的，请开发的时候不要使用这个
            return Send(command);//请注意 入参 的类型
        }

        /// <summary>
        /// Mdtiator Send方法源码
        /// </summary>
        /// <typeparam name="TResponse">泛型</typeparam>
        /// <param name="request">请求命令</param>
        /// <param name="cancellationToken">用来控制线程Task</param>
        /// <returns></returns>
        public Task<TResponse> Send<TResponse>(IRequest<TResponse> request, CancellationToken cancellationToken = default)
        {
            // 判断请求是否为空
            if (request == null)
            {
                throw new ArgumentNullException(nameof(request));
            }
            // 获取请求命令类型
            var requestType = request.GetType();

            // 对咱们的命令进行封装
            // 请求处理程序包装器
            var handler = (RequestHandlerWrapper<TResponse>)_requestHandlers.GetOrAdd(requestType,
                t => Activator.CreateInstance(typeof(RequestHandlerWrapperImpl<,>).MakeGenericType(requestType, typeof(TResponse))));

              //↑↑↑↑↑↑↑ 这以上是第二步 ↑↑↑↑↑↑↑↑↑↑

 
 

 　　　　　　    //↓↓↓↓↓↓↓ 第三步开始  ↓↓↓↓↓↓↓↓↓
 
 
// 执行封装好的处理程序
            // 说白了就是执行咱们的命令
            return handler.Handle(request, cancellationToken, _serviceFactory);
        }
    }
}
 

 

 
 

上边的方法的第二步中，咱们获取到了 handler ，这个时候，咱们已经把 RegisterStudentCommand 命令，包装成了 RequestHandlerWrapper<RegisterStudentCommand> ，那如何成功的定位到 StudentCommandHandler.cs 呢，请继续往下看。(你要是问我做者具体是咋封装的，请看源码，或者给他发邮件，说不定你还能够成为他的开发者之一哟 ~)
 

 
 

三、服务工厂调用指定的处理程序
 

 咱们获取到了 handler 之后，就去执行该处理程序
 

 
 
handler.Handle(request, cancellationToken, _serviceFactory);
 

 

 
 

咱们看到 这个handler 仍是一个抽象类 internal abstract class RequestHandlerWrapper<TResponse> ，接下来，咱们就是经过 .Handle() ，对抽象类进行实现
 

 

 

上图的过程是这样：
 

 
 
一、访问类方法  handler.Handle() ；
 
 
二、是一个管道处理程序，要包围内部处理程序的管道行为，实现添加其余行为并等待下一个委托。
 
 
三、就是调用了这个匿名方法；
 
 
四、执行GetHandler() 方法；
 

 

 
 

其实从上边简单的看出来，就是实现了请求处理程序从抽象到实现的过程，而后添加管道，并下一步要对该处理程序进行实例化的过程，说白了就是把 RequestHandlerWrapper<RegisterStudentCommand> 给转换成 IRequestHandler<RegisterStudentCommand>  的过程，而后下一步给 new 了一下。但是这个时候你会问，那实例化，确定得有一个对象吧，这个接口本身确定没法实例化的，没错！若是你能想到这里，证实你已经接近成功了，请继续往下看。
 

 
 

四、经过注入，实例化咱们的处理程序
 

在上边的步骤中，咱们知道了一个命令是如何封装成了特定的处理程序接口，而后又是在哪里进行实例化的，可是具体实例化成什么样的对象呢，就是在咱们的 IoC 中：
 

 
 
 // Domain - Commands
 // 将命令模型和命令处理程序匹配
 services.AddScoped<IRequestHandler<RegisterStudentCommand, Unit>, StudentCommandHandler>();
 services.AddScoped<IRequestHandler<UpdateStudentCommand, Unit>, StudentCommandHandler>();
 services.AddScoped<IRequestHandler<RemoveStudentCommand, Unit>, StudentCommandHandler>();
 

 

 
 

若是你对依赖注入很了解的话，你一眼就能明白这个的意义是什么：
 

依赖注入 services.AddScoped<A, B>();意思就是，当咱们在使用或者实例化接口对象 A 的时候，会在容器中自动匹配，并寻找与之对应的类对象 B。说到这里你应该也就明白了，在第三步中，咱们经过 GetInstance，对咱们包装后的命令处理程序进行实例化的时候，自动寻找到了 StudentCommandHandler.cs 类。
 

 
 

 
 

五、匹配具体的命令处理方法
 

这个很简单，在第四步以后，紧接着就是自动寻找到了 Task<Unit> Handle(RegisterStudentCommand message, CancellationToken cancellationToken) 方法，整个流程就这么结束了。
 

 

 
 

如今这个流程你应该已经很清晰了，或者大概了解了总体过程，还有一个小问题就是，咱们如何将错误信息收集的，在以前的Controller 里写业务逻辑的时候，用的是 ViewBag，那类库是确定不能这么用的，为了讲解效果，我暂时用缓存替换，明天咱们会用领域事件来深刻讲解。
 

 
 

3、用缓存来记录错误通知
 

这里仅仅是一个小小的乱入补充，上边已经把流程调通了，若是你想看看什么效果，这里就出现了一个问题，咱们的错误通知信息没有办法获取，由于以前咱们用的是ViewBag，这里无效，固然Session等都无效了，由于咱们是在整个项目的多个类库之间使用，只能用 Memory 缓存了。
 

一、命令处理程序基类CommandHandler 中，添加公共方法
 

 
 
//将领域命令中的验证错误信息收集
//目前用的是缓存方法（之后经过领域通知替换）
protected void NotifyValidationErrors(Command message)
{
    List<string> errorInfo = new List<string>();
    foreach (var error in message.ValidationResult.Errors)
    {
        errorInfo.Add(error.ErrorMessage);

    }
    //将错误信息收集
    _cache.Set("ErrorData", errorInfo);
}
 

 

二、在Student命令处理程序中调用
 

 
 

三、自定义视图模型中加载
 

 
 
/// <summary>
/// Alerts 视图组件
/// 能够异步，也能够同步，注意方法名称，同步的时候是Invoke
/// 我写异步是为了为之后作准备
/// </summary>
/// <returns></returns>
public async Task<IViewComponentResult> InvokeAsync()
{
    // 获取到缓存中的错误信息
    var errorData = _cache.Get("ErrorData");
    var notificacoes = await Task.Run(() => (List<string>)errorData);
    // 遍历添加到ViewData.ModelState 中
    notificacoes?.ForEach(c => ViewData.ModelState.AddModelError(string.Empty, c));

    return View();
}
 

 

这都是很简单，就很少说了，下一讲的领域事件，再好好说吧。
 

 这个时候记得要在API的controller中，每次把缓存清空。
 

 

 
 

四、效果浏览
 

 

 
 

总体流程就是这样：
 

 
 

 
 

4、结语
 

 上边的流程想必你已经看懂了，或者说七七八八，可是，至少你如今应该明白了，中介者模式，是如何经过命令总线Bus，把命令发出去，又是为何在领域层的处理程序里接受到的，最后又是如何执行的，若是仍是不懂，请继续看一看，或者结合代码，调试一下。咱们能够这样来讲，请求以命令的形式包裹在对象中，并传给调用者。调用者（代理）对象查找能够处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令 。
 

若是你看到这里了，那你下一节的领域事件，就很驾轻就熟，这里有两个问题遗留下来：
 

 
 
一、咱们记录错误信息，缓存很很差，还须要每次清理，不是基于事务的，那如何替换呢？
 
 
二、MediatR有两个经常使用方法，一个是请求/响应模式，另外一个发布模式如何使用么？
 

 

若是你很好奇，那就请看下回分解吧~~ 
 

 
 

5、GitHub & Gitee
 

https://github.com/anjoy8/ChristDDD
 

https://gitee.com/laozhangIsPhi/ChristDDD 
 

 
 

--End


        

            

        	





    

		

            
相关文章

            

                

                

                    

                

            


            
相关标签/搜索

            
        


    

        

            

        

        

        
        

        

        

    




	

    





    

    	

    

        每日一句
    

    
    
    	每一个你不满意的现在，都有一个你没有努力的曾经。
    







    

    


    



    

        本站公众号
    

    

           欢迎关注本站公众号,获取更多信息

        
    




    

    




	


	







    

        联系我们
        最近搜索
        最新文章
        
        沪ICP备13005482号-10

            MyBatis教程
            SQL 教程
            MySQL教程
            Java 教程
            Thymeleaf 教程
            Hibernate教程
            Spring教程 
            Redis教程