本篇是对MediatR知识点的一个总结,内容来源于网络。
MediatR是进程内的消息订阅、发布框架。中介者模式的一种实现
什么是中介者模式
定义一个中介对象来封装一系列对象之间的交互,使原有对象之间的耦合松散,且可以独立地改变它们之间的交互。中介者模式又叫调停模式,它是迪米特法则的典型应用。
MediatR消息模式
1、Request/Response 请求响应模式
一个请求只能被一个处理者捕获,如果存在多个处理者,那么只有最后一个处理者会被激活。
具体怎么使用,网上很多,这里不再赘述。
优势:
请求响应模式将“方法的调用者”与“方法的实现者”解耦。但是个人认为这并是不很大的优势。两者之间还是有强关联,只不过不需要在“方法的调用者”中注入“方法的实现者”。
也是命令模式的实现
将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通。(自己感觉是一个东西那么多种模式叫法)
可以实现CQRS:
CQRS 的全称是:"Command and Query Responsibility Segregation",直译过来就是命令与查询责任分离,可以通俗的理解为 读写分离。(个人以为又是一个鸡肋的新词)
CQRS 使用命令来更新数据,使用查询来读取数据,将读取和写入 分离到不同的 模型中
管道:
MediatR提供与管道行为相同的功能。可以在响应之前、之后注入相关逻辑,比如记录日志,内容检查等。
编写一个类实现IPipelineBehavior:
- class LoggingBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
- {
- private readonly Logger _logger;
-
- public LoggingBehavior(Logger logger)
- {
- _logger = logger;
- }
-
- public async Task
Handle - (TRequest request, CancellationToken cancellationToken,
- RequestHandlerDelegate
next ) - {
- try
- {
- _logger.Log($"Before execution for {typeof(TRequest).Name}");
-
- return await next();
- }
- finally
- {
- _logger.Log($"After execution for {typeof(TRequest).Name}");
- }
- }
- }
注册它:
- services.AddMediatR(typeof(Startup));
- services.AddScoped(typeof(IPipelineBehavior<,>), typeof(LoggingBehavior<,>));
所有注册的管道行为都将按照注册顺序与每个请求处理程序一起执行。(引自:https://blog.csdn.net/mzl87/article/details/123602433)
2、Notification 发布模式
一般是一个发布者,多个订阅者。虽然有一定的顺序(经测试是按照类的先后顺序来的),但是这里的重点是“”广播“”,不要有依赖顺序的逻辑。
默认情况下,MediatR的消息发布是一个一个执行的,即便是返回Task的情况,也是使用await等待上一个执行完成后才进行下一个的调用。如果需要使用并行的方法进行调用,可以进行定制,具体可参考官方示例:MediatR.Examples.PublishStrategies
主要参考:
https://blog.csdn.net/mzl87/article/details/123602433
https://www.cnblogs.com/yakniu/p/16376823.html
https://zhuanlan.zhihu.com/p/441606336