C#如何实现CQRS模式 MediatR库入门与实践指南

MediatR是C#中实现CQRS最轻量主流的选择，以“请求-响应”模型分离命令与查询，提升可测性与扩展性；它作为进程内消息总线自动路由请求到唯一处理器，不强制接口，需自行组合事务、缓存等能力。

在C#中实现CQRS模式，MediatR是最轻量、最主流的选择之一。它不强制你写一堆接口和基类，而是用“请求-响应”模型自然地把命令（Command）和查询（Query）分开，让业务逻辑更清晰、可测试性更强、扩展更灵活。

一、理解CQRS与MediatR的核心分工

CQRS（Command Query Responsibility Segregation）本质是把“改数据”和“读数据”彻底拆开：命令负责修改状态（如创建订单、更新用户），查询只负责返回数据（如获取用户列表、查订单详情）。MediatR不是CQRS框架，而是一个进程内消息总线——它帮你把请求（IRequest）发给唯一对应的处理器（IRequestHandler），自动完成路由、依赖注入和生命周期管理。

关键点：

• 一个请求类型（比如CreateUserCommand）只能有一个处理器；
• 查询和命令都用IRequest<tresponse></tresponse>统一建模，是否修改数据库由你决定；
• MediatR本身不处理事务、缓存或事件发布，这些需你自行组合（比如配合Entity Framework Core + IUnitOfWork + IDomainEvent）。

二、快速上手：三步接入MediatR

以.net 6+项目为例（控制台或Web API均可）：

1. 安装包

通过NuGet安装：
MediatR（核心库）
MediatR.Extensions.microsoft.DependencyInjection（集成ASP.NET Core DI）

2. 注册服务

在Program.cs中添加：

builder.Services.AddMediatR(cfg => cfg.RegisterServicesFromAssembly(typeof(Program).Assembly));

这会自动扫描当前程序集下所有实现了IRequestHandler或INotificationHandler的类并注册。

3. 写一个查询示例

定义查询请求：

慧中标AI标书

慧中标ai标书是一款AI智能辅助写标书工具。

295

查看详情

public record GetUserByIdQuery(int Id) : IRequest<UserDto>;

定义处理器：

public class GetUserByIdQueryHandler : IRequestHandler<GetUserByIdQuery, UserDto> {     private readonly IUserRepository _repo;     public GetUserByIdQueryHandler(IUserRepository repo) => _repo = repo;      public async Task<UserDto> Handle(GetUserByIdQuery request, CancellationToken ct)         => await _repo.GetByIdAsync(request.Id, ct); }

在Controller中使用：

[HttpGet("{id}")] public async Task<ActionResult<UserDto>> Get(int id)     => Ok(await _mediator.Send(new GetUserByIdQuery(id)));

三、命令与验证的最佳实践

命令通常伴随业务规则校验。推荐组合FluentValidation：

• 为每个命令定义对应Validator（如CreateUserCommandValidator : AbstractValidator<createusercommand></createusercommand>）；
• 安装MediatR.Extensions.FluentValidation.AspNetCore，自动启用验证管道行为；
• 验证失败时直接返回ValidationException，可在全局Filter中统一转为400响应。

命令执行后若需通知其他模块（如发邮件、更新搜索索引），不要在Handler里硬编码调用。改用INotification + INotificationHandler解耦：

await _mediator.Publish(new UserCreatedNotification(user), ct);

多个Handler可同时监听该事件，互不影响。

四、常见陷阱与应对建议

别把MediatR当Service Locator用：避免在Handler里通过IMediator再发另一个请求——这容易导致隐式调用链、事务边界混乱、难以调试。需要组合逻辑？提取成领域服务，由Handler协调。

事务控制要明确：MediatR不管理事务。命令Handler中若涉及EF Core操作，应在最外层（如中间件或基类Handler）开启DbContextTransaction，或用IUnitOfWork封装。

查询不要偷偷改状态：虽然技术上可以，但违背CQRS语义。如果某个“查询”必须触发副作用（如记录访问日志），应显式命名为TrackUserViewQuery，并在文档/命名中体现其非纯查询性质。

异步要到底：所有Handler方法必须标记async Task<t></t>，不要用.Result或.Wait()阻塞——尤其在Web环境下会导致线程饥饿。

基本上就这些。MediatR本身很薄，真正考验的是你对领域边界的划分能力。用好它，不是为了炫技，而是让每个类只做一件事：接收请求、专注逻辑、返回结果。