C# MediatR使用方法 C#如何实现CQRS模式

MediatR 初始化必须注册 IMediator 接口，否则注入时抛 InvalidOperationException；ASP.NET Core 6+ 用 AddMediatR()，跨类库需显式传入程序集；IRequest 用于无返回值操作，IRequest 用于需返回值场景；Handler 必须严格匹配泛型参数；CQRS 核心是职责与模型隔离，非仅命名；管道行为适合横切逻辑但需注意执行顺序与异常处理；数据一致性策略才是 CQRS 复杂所在。

MediatR 初始化必须注册 IMediator 接口

不注册 IMediator 就直接注入会报 InvalidOperationException: Unable to resolve service for type 'MediatR.IMediator'。ASP.NET Core 6+ 默认用 AddMediatR() 扩展方法，但要注意参数——它默认只扫描当前程序集，跨类库时得显式传入程序集：

• 单项目：直接 services.AddMediatR(cfg => cfg.RegisterServicesFromAssembly(typeof(Program).Assembly));
• 命令/查询/处理逻辑在独立类库中：必须把对应程序集加进去，比如 AddMediatR(typeof(CreateUserCommandHandler).Assembly)
• 别漏掉 using MediatR;，否则 AddMediatR 方法不可见

IRequest 和 IRequest

的选择取决于是否需要返回值

写请求类时，用 IRequest 表示“只发不收”（如发送邮件、触发日志），用 IRequest 表示“发完要等结果”（如查用户、生成订单号）。选错会导致编译失败或运行时报 Cannot convert lambda expression 类型错误：

• 无返回值示例：public record CreateUserCommand(string Name) : IRequest;
• 有返回值示例：public record GetUserQuery(Guid Id) : IRequest;
• Handler 类必须严格匹配泛型参数：public class GetUserQueryHandler : IRequestHandler

CQRS 分离的关键不是命名，而是职责和生命周期

很多人以为只要把类名写成 “Query/Command” 就算 CQRS，其实核心是：查询不改状态、命令不返回领域数据、读写模型物理隔离（哪怕一开始共用 EF Core DbContext）。常见踩坑点：

• 在 IRequestHandler 里调用 _context.SaveChanges() —— 这属于命令逻辑，不该出现在 Query Handler 中
• Query Handler 返回 Entity 而非 DTO，导致序列化时触发 EF 延迟加载或循环引用
• 所有 Handler 都用同一个 DbContext 实例（Scoped 生命周期），但没做读写分离配置，缓存/事务行为容易互相干扰

MediatR 管道行为（Pipeline Behavior）适合横切逻辑，但别滥用

比如日志、验证、权限检查，用 IPipelineBehavior 比在每个 Handler 里重复写更干净。但要注意执行顺序和异常传播：

• 多个 Behavior 按注册顺序“套娃”，先注册的在外层；想让验证最先执行，就第一个 AddTransient
• 在 Behavior 中 throw 异常会中断后续 Handler，但 ValidationException 不该被吞掉，否则前端拿不到具体错误字段
• 不要在 Behavior 里 new DbContext 或手动管理事务——它可能跨多个 Handler，而事务应由最外层命令控制

CQRS 的真正复杂点不在 MediatR 怎么配，而在读写模型的数据一致性策略：是用事件总线最终一致，还是同步双写，抑或共享数据库但分 Schema。这些决策会影响 Handler 里要不要发事件、要不要加重试、要不要补偿逻辑——而 MediatR 本身只负责调用链路，不解决这些问题。