.NET Core开发实战（第34课：MediatR：轻松实现命令查询职责分离模式（CQRS））--学习笔记（上）...

34 | MediatR：轻松实现命令查询职责分离模式（CQRS）

核心对象

IMeditator

IRequese、IRequest

IRequestHandler<in TRequest, TResponse>

源码链接：
https://github.com/witskeeper/geektime/tree/master/samples/MediatorDemo

首先我们安装了 MediatR 的 8.0 的组件包，还安装了依赖注入框架的扩展包，以及依赖注入框架的核心组件包

• MediatR

• MediatR.Extensions.Microsoft.DependencyInjection

• Microsoft.Extensions.DependencyInjection

大家可以观察到 MediatR 的包名和命名空间少了一个 o，猜测是作者故意这样设计的，因为它具体实现里面会有一个接口和类是 Mediator，如果设置同名的话会有一些引用上的问题

var services = new ServiceCollection();

services.AddMediatR(typeof(Program).Assembly);

我们在这里构建一个 ServiceCollection，然后通过一行代码将我们当前的程序集注入进去，它就可以扫描我们当前程序集相关的类，下面看一下我们定义的两个类

internal class MyCommand : IRequest<long>
{
    public string CommandName { get; set; }
}

internal class MyCommandHandler : IRequestHandler<MyCommand, long>
{
    public Task<long> Handle(MyCommand request, CancellationToken cancellationToken)
    {
        Console.WriteLine($"MyCommandHandler执行命令：{request.CommandName}");
        return Task.FromResult(10L);
    }
}

第一个类是 MyCommand，它实现了 IRequest 接口，这个接口就代表中介者要执行的命令

第二个类是 MyCommandHandler，它实现了 IRequestHandler 的接口，这个就是我们对命令的处理器的定义

var serviceProvider = services.BuildServiceProvider();

var mediator = serviceProvider.GetService<IMediator>();

await mediator.Send(new MyCommand { CommandName = "cmd01" });

我们从容器里面获取一个 IMediator，然后通过 send 方法发送一个 MyCommand 命令，我们构造了一个新的 MyCommand 的实例传给它

启动程序，输出如下：

MyCommandHandler执行命令：cmd01

我们可以看到 MyCommandHandler 的 Handle 方法执行了，它输出了 MyCommandHandler 的执行命令 cmd01

这样子，这个中介者它有什么好处呢?

大家可以看到，通过中介者模式，我们将命令的构造和命令的处理可以分离开，那么命令的处理如何知道要处理哪个命令呢，就是通过我们泛型的约束来定义的，我们这里为 IRequestHandler 填入了 MyCommand 类型，所以我们能明确知道 MyCommandHandler 是用来处理 MyCommand 的

如果说我在程序里面实现了多个 Handler，我们可以试验一下

internal class MyEventHandlerV2 : INotificationHandler<MyEvent>
{
    public Task Handle(MyEvent notification, CancellationToken cancellationToken)
    {
        Console.WriteLine($"MyEventHandlerV2执行：{notification.EventName}");
        return Task.CompletedTask;
    }
}

启动程序，输出如下：

MyCommandHandlerV2执行命令：cmd01

大家可以看到我们输出的是 V2 执行命令

我们把代码进行一个调整，把这个定义移到后面

internal class MyEventHandler : INotificationHandler<MyEvent>
{
    public Task Handle(MyEvent notification, CancellationToken cancellationToken)
    {
        Console.WriteLine($"MyEventHandler执行：{notification.EventName}");
        return Task.CompletedTask;
    }
}

internal class MyEventHandlerV2 : INotificationHandler<MyEvent>
{
    public Task Handle(MyEvent notification, CancellationToken cancellationToken)
    {
        Console.WriteLine($"MyEventHandlerV2执行：{notification.EventName}");
        return Task.CompletedTask;
    }
}

启动程序，输出如下：

MyCommandHandler执行命令：cmd01

大家可以看到我们这次输出的并不是 V2，而是之前的那个命令，为什么会这样子呢？是因为实际上 mediator 对于 IRequestHandler 的扫描，它是有顺序的，后面扫描到的会替换前面扫描到的 Handler，它只会识别其中最后注册进去的一个，也就是说我们在处理 RequestHandler 的时候，我们要注意在注册时仅注册需要的那个

我们再来看看我们的应用程序，回到我们之前的工程里

namespace GeekTime.API.Application.Commands
{
    public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, long>
    {
        IOrderRepository _orderRepository;
        ICapPublisher _capPublisher;
        public CreateOrderCommandHandler(IOrderRepository orderRepository, ICapPublisher capPublisher)
        {
            _orderRepository = orderRepository;
            _capPublisher = capPublisher;
        }


        public async Task<long> Handle(CreateOrderCommand request, CancellationToken cancellationToken)
        {

            var address = new Address("wen san lu", "hangzhou", "310000");
            var order = new Order("xiaohong1999", "xiaohong", 25, address);

            _orderRepository.Add(order);
            await _orderRepository.UnitOfWork.SaveEntitiesAsync(cancellationToken);
            return order.Id;
        }
    }
}

我们可以看到我们的 CreateOrderCommandHandler 实现的是 IRequestHandler，这也就是解释了为什么之前我们并没有显示的调用 CreateOrderCommandHandler，代码却能够执行到这里的原因