您认为用 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，我不能有一个用于创建、更新和删除的模型，所以重用它的一种方法是我需要派生如下请求：
public CreateRequest : MyDto, IRequest<MyDto> {}
public UpdateRequest : MyDto, IRequest<MyDto> {}
或将其嵌入我的命令中，例如：
public CreateRequest : IRequest<MyDto>
{
MyDto MyDto { get; set; }
}
MediatR 的一个优点是能够轻松插入和拔出逻辑，这似乎非常适合模块化架构，但我仍然有点困惑如何用它来塑造我的架构。