MediatR CQRS实战教程IRequest命令查询分离彻底解耦.NET业务逻辑【免费下载链接】MediatRSimple, unambitious mediator implementation in .NET项目地址: https://gitcode.com/gh_mirrors/me/MediatRMediatR是 .NET 生态中最流行的中介者Mediator库它以简单、无野心为设计理念用IRequest请求-响应模型天然支持CQRS 命令查询分离让你无需手动编写依赖注入的胶水代码就能彻底解耦 .NET 业务逻辑。 为什么需要 MediatR传统 .NET 业务代码常常长成这样Controller 直接调用 ServiceService 里堆满 if/else请求分发、依赖注入、横切逻辑日志、缓存、事务全搅在一起——业务逻辑越写越缠绕。MediatR 的解法很优雅把你的业务意图定义为一个请求Request交给中介者IMediator它会自动找到对应的处理器Handler并执行。痛点MediatR 的解法调用链层层耦合请求与处理器之间零引用靠类型自动匹配手动写依赖注入胶水代码AddMediatR一行注册程序集自动扫描日志/缓存等横切逻辑难插入Pipeline Behavior 洋葱模型无侵入包装命令写与查询读混杂IRequestT请求-响应模型天然支持 CQRS 快速安装与注册通过 NuGet 安装后只需一行完成服务注册dotnet add package MediatRservices.AddMediatR(cfg cfg.RegisterServicesFromAssemblyContainingProgram());注册后IMediator、ISender、IPublisher以及程序集中的所有 Handler 都会被自动注册为瞬态Transient服务。注册细节可参考 MediatRServiceCollectionExtensions.cs。 核心概念IRequest 是 CQRS 的基石MediatR 的请求契约只有 3 个标记接口位于独立的 MediatR.Contracts 包中接口含义CQRS 角色IRequestTResponse有返回值的请求Query查询——一问一答IRequest无返回值的请求Command命令——只执行INotification通知/事件发布-订阅一对多这种标记接口 泛型的设计妙处在于请求类型即路由。IMediator无需任何配置仅凭泛型参数就能把请求精准分发到唯一匹配的 HandlerIRequestHandler.cs而INotification则会被广播给所有处理器。一个命令一次发送官方示例中最经典的 Ping/Pong 演示命令与查询一目了然// 请求契约——定义在 [Ping.cs](https://link.gitcode.com/i/52c9f926258bf93b73ccfc94cb9b9c72) public class Ping : IRequestPong { public string Message { get; set; } } // 处理器 —— 实现见 [PingHandler.cs](https://link.gitcode.com/i/3a79a1dfc44b15c8dfc2fb3d2384ab27) // 业务代码中只需 var pong await mediator.Send(new Ping { Message Ping });Send会触发单一处理器语义一个IRequest只被一个 Handler 处理这正是 CQRS 中 Command/Query 的行为保证。发送入口定义在 ISender.cs。一个通知多方响应而Publish走的是广播语义适合订单创建后同时发通知、写日志、发积分等多个 Handler 各取所需的场景await mediator.Publish(new Pinged()); // 广播给所有 INotificationHandlerPinged处理器接口见 INotificationHandler.cs。经验法则会改变状态 → 用IRequest命令要拿数据 → 用IRequestT查询只是发生了什么事 → 用INotification事件。️ CQRS 实战解耦三步走第 1 步按意图拆分请求把下单和查订单定义成两个请求类型而不是一个带 action 参数的大方法CreateOrder : IRequestOrderId—— 命令GetOrderById : IRequestOrderDto—— 查询第 2 步处理器各司其职每个请求对应一个 Handler业务逻辑被隔离在独立的类中单元测试时直接 new 出来即可无需拉起整个容器。第 3 步用 Pipeline 插入横切逻辑MediatR 的管道行为Pipeline Behavior是它的杀手锏——洋葱模型前处理器PreProcessor └─ Behavior日志 / 缓存 / 事务 └─ 真正的 Handler 执行 └─ 后处理器PostProcessor内置的前/后处理器位于 Pipeline 目录异常处理则通过 RequestExceptionProcessorBehavior.cs 实现让异常策略也参与管道编排。你可以查询缓存写一个 Behavior命中缓存直接短路不进数据库命令加事务只对命令管道开启事务查询管道保持轻量统一日志无需在每个 Handler 里重复写 try/catch。这正是彻底解耦的含义业务 Handler 只管业务横切关注点全部外置到管道。 Send vs Publish一张图看懂分发策略mediator.Send(request) mediator.Publish(notification) │ │ ▼ ▼ 唯一 Handler N 个 Handler 全部执行 一问一答 / CQRS 命令查询 广播 / 事件解耦两种策略的派发器实现可见 NotificationPublishers顺序执行 vsTask.WhenAll并发执行可选。完整的可运行演示在 samples/MediatR.Examples/Runner.cs它依次演示了请求、通知、流式请求与异常管道的全流程samples/MediatR.Examples.AspNetCore/Program.cs 则展示了 ASP.NET Core 环境下的注册方式。⚙️ 进阶能力一览能力说明参考流式请求IStreamRequestT支持await foreach消费结果流IStreamRequest.cs管道顺序控制实现IOrderedPipelineBehavior可固定 Behavior 执行顺序IPipelineBehavior.cs开放泛型 Behavior一个泛型 Behavior 覆盖所有请求配合约束samples 中的 GenericPipelineBehavior.csContracts 独立包契约与实现分程序集适用于 API/GRPC/Blazor 场景MediatR.Contracts.csproj多容器支持Autofac、DryIoc、Lamar、Windsor 等各有官方示例samples/✅ 总结MediatR 让 CQRS 落地只需三行认知IRequestT 查询IRequest 命令——类型即路由Send单一分发INotification 事件——Publish广播分发天然解耦副作用Pipeline 洋葱——日志、缓存、事务、异常策略全部无侵入地包在业务之外。MediatR 用最小的 API 面核心接口仅 IMediator.cs、ISender.cs、IPublisher.cs 三个文件换来了最大的解耦收益你的业务代码不再关心谁调用了谁只关心请求如何被处理。现在就打开 README.md 安装 MediatR用 10 分钟把第一个 Handler 跑起来吧 【免费下载链接】MediatRSimple, unambitious mediator implementation in .NET项目地址: https://gitcode.com/gh_mirrors/me/MediatR创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考