c# - 用MediatR替换服务层-值得这样做吗？

您认为用MediatR替换我的服务层或服务类是否合理？例如，我的服务类如下所示：

public interface IEntityService<TEntityDto> where TEntityDto : class, IDto
{
    Task<TEntityDto> CreateAsync(TEntityDto entityDto);
    Task<bool> DeleteAsync(int id);
    Task<IEnumerable<TEntityDto>> GetAllAsync(SieveModel sieveModel);
    Task<TEntityDto> GetByIdAsync(int id);
    Task<TEntityDto> UpdateAsync(int id, TEntityDto entityDto);
}

我想实现某种模块化设计，以便其他动态加载的模块
 或插件可以为我的主要核心应用程序编写自己的通知或命令处理程序。

当前，我的应用程序根本不是事件驱动的，而且动态加载的插件之间没有简单的通信方式。

我可以将MediatR并入控制器中以完全删除服务层，也可以将其与服务层一起使用，仅发布通知，以便我的插件可以处理它们。

当前，我的逻辑主要是CRUD，但是在创建，更新，删除之前有很多自定义逻辑。

我的服务可能会替换为：

public class CommandHandler : IRequestHandler<CreateCommand, Response>, IRequestHandler<UpdateCommand, Response>, IRequestHandler<DeleteCommand, bool>
{
    private readonly DbContext _dbContext;

    public CommandHandler(DbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public Task<Response> Handle(CreateCommand request, CancellationToken cancellationToken)
    {
        //...
    }

    public Task<Response> Handle(UpdateCommand request, CancellationToken cancellationToken)
    {
        //...
    }

    public Task<bool> Handle(DeleteCommand request, CancellationToken cancellationToken)
    {
        ///...
    }
}

会做错事吗？

基本上，我正在为逻辑流程选择什么：


控制器->服务-> MediatR->通知处理程序->存储库
控制器-> MediatR->命令处理程序->存储库


似乎对于MediatR，我无法为Create，Update和Delete建立单一模型，因此，要重用它的一种方法，我需要派生以下请求：

public CreateRequest : MyDto, IRequest<MyDto> {}
public UpdateRequest : MyDto, IRequest<MyDto> {}

或将其嵌入我的命令中，例如：

public CreateRequest : IRequest<MyDto>
{
    MyDto MyDto { get; set; }
}

MediatR的一个优点是能够轻松插入和插入逻辑，这似乎很适合模块化体系结构，但是我还是有点困惑如何用它来构建体系结构。

最佳答案

在这里部分回答了此问题：MediatR when and why I should use it? vs 2017 webapi

使用MediaR（或MicroBus或任何其他介体实现）的最大好处是isolating and/or segregating您的逻辑（其使用CQRS的流行方法的原因之一）和实现decorator pattern的良好基础（例如ASP.NET）核心MVC过滤器）。从MediatR 3.0开始，它对此提供了内置支持（请参见Behaviours）（而不是使用IoC装饰器）

您也可以将装饰器模式用于服务（如FooService之类的类）。您也可以将CQRS与服务一起使用（FooReadService，FooWriteService）

除此之外，它基于观点，并使用您想要实现的目标。除了代码维护，最终结果应该没有任何区别。

补充阅读：


Baking Round Shaped Apps with MediatR
（将自定义中介程序的实现与MediatR提供的一种和移植过程进行了比较）
Is it good to handle multiple requests in a single handler?