当前位置: 代码迷 >> 综合 >> .NET Core开发实战(第34课:MediatR:轻松实现命令查询职责分离模式(CQRS))--学习笔记(上)...
  详细解决方案

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

热度:37   发布时间:2024-01-12 09:57:05.0

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,代码却能够执行到这里的原因

  相关解决方案