【发布时间】：2018-11-22 21:36:16
【问题描述】：
您认为将我的服务层或服务类替换为 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 的一个优点是能够轻松插入和拔出逻辑，这似乎非常适合模块化架构，但我仍然有点困惑如何用它来塑造我的架构。
【问题讨论】：
-
在这里扮演魔鬼的拥护者是一篇关于为什么在将其带入项目之前需要三思而后行的帖子 - alex-klaus.com/mediator
标签： c# asp.net-core domain-driven-design soa mediatr