深入了解MediatR：简化请求处理的中介者模式库它是请求 MediatR 库的核心组件

2024-07-01 03:00:00 [百科] 来源：避面尹邢网

深入了解MediatR：简化请求处理的深入中介者模式库

作者：小乖兽技术 2023-09-27 08:43:17开源通过使用 MediatR，开发人员可以更好地组织和解耦应用程序中的解M简化介逻辑，将请求和通知的请求处理逻辑集中到单独的处理程序中，提高代码的处理可维护性和可测试性。

基本概念

MediatR 是模式一个开源的中介者模式库，用于在应用程序中实现请求和通知的深入处理。它提供了以下基本内容：

深入了解MediatR：简化请求处理的中介者模式库它是请求 MediatR 库的核心组件

中介者（Mediator）：负责协调请求和通知的解M简化介处理。它是请求 MediatR 库的核心组件，通过将请求和通知发送给相应的处理处理程序来实现解耦和逻辑的处理。
请求处理（Request Handling）：MediatR 支持处理各种类型的模式请求，并将其分发给相应的深入请求处理程序。请求处理程序实现了 IRequestHandler 接口，解M简化介接收具体的请求请求类型并执行相应的处理逻辑。
请求（Request）：请求是处理对应用程序执行某个操作的命令或查询。在 MediatR 中，模式请求可以由 IRequest 接口定义，可以是带有返回结果的（即 IRequest<TResponse>），也可以是没有返回结果的。
通知处理（Notification Handling）：除了请求，MediatR 还支持发布通知并将其分发给相应的通知处理程序。通知处理程序实现了 INotificationHandler 接口，接收特定类型的通知并执行相应的处理逻辑。
通知（Notification）：通知是向应用程序中的其他部分广播消息的对象。与请求不同，通知不需要返回结果，只需让对应的通知处理程序执行相应的操作。

通过使用 MediatR，开发人员可以更好地组织和解耦应用程序中的逻辑，将请求和通知的处理逻辑集中到单独的处理程序中，提高代码的可维护性和可测试性。

深入了解MediatR：简化请求处理的中介者模式库它是请求 MediatR 库的核心组件

请求与处理

在 MediatR 中，请求和处理是其中一个核心概念，用于实现请求-响应模式的消息通信。主要内容包括如下：

深入了解MediatR：简化请求处理的中介者模式库它是请求 MediatR 库的核心组件

请求（Request）：请求是一个命令或查询，用于向应用程序发送指令或获取特定的数据。在 MediatR 中，请求可以是带有返回结果的（即 IRequest<TResponse>），也可以是没有返回结果的。请求对象应该实现相应的请求接口，并定义所需的属性和方法。
请求处理（Request Handling）：请求处理是指对请求进行处理的过程。在 MediatR 中，请求处理程序实现了 IRequestHandler<TRequest, TResponse> 接口，负责接收特定类型的请求并执行相应的逻辑操作。请求处理程序通过实现接口中的 Handle() 方法来处理请求，并返回相应的结果（如果有的话）。
发送请求（Send Request）：使用 MediatR 发送请求时，可以通过中介者（Mediator）的 Send() 方法将请求发送给相应的请求处理程序。Send() 方法会找到适配的请求处理程序，并将请求传递给它进行处理。如果请求是带有返回结果的，则 Send() 方法会返回处理后的结果。
异步请求处理：MediatR 支持异步请求处理，可以通过实现异步版本的请求处理方法实现。异步请求处理程序应该实现 Task<TResponse> HandleAsync(TRequest request, CancellationToken cancellationToken) 方法，用于异步处理请求。

使用 MediatR 的请求与处理模式可以带来许多好处，例如解耦请求和处理逻辑、提升代码的可维护性和可测试性、简化控制流程等。通过使用中介者模式，请求和处理之间的依赖关系被限制在中介者之间，使得系统更加灵活和可扩展。

通知与处理

在 MediatR 中，通知和处理是另一个核心概念，用于实现发布-订阅模式的消息通信。主要内容包括如下：

通知（Notification）：通知是一种消息，用于向应用程序中的其他部分广播信息。通知不需要返回结果，只需让对应的通知处理程序执行相应的操作。在 MediatR 中，通知对象是一个简单的类，没有特定的接口要求，只需要定义所需的属性和方法。
通知处理（Notification Handling）：通知处理是指对通知进行处理的过程。在 MediatR 中，通知处理程序实现了 INotificationHandler<TNotification> 接口，负责接收特定类型的通知并执行相应的逻辑操作。通知处理程序通过实现接口中的 Handle() 方法来处理通知。
发布通知（Publish Notification）：使用 MediatR 发布通知时，可以通过中介者（Mediator）的 Publish() 方法将通知发布给所有对应的通知处理程序。Publish() 方法会找到匹配的通知处理程序，并将通知传递给它们进行处理。不同于请求，通知不需要返回结果。
异步通知处理：MediatR 同样支持异步通知处理，可以通过实现异步版本的通知处理方法实现。异步通知处理程序应该实现 Task Handle(TNotification notification, CancellationToken cancellationToken) 方法，用于异步处理通知。

使用 MediatR 的通知与处理模式可以实现松耦合的消息通信，将发布者和订阅者之间解耦，并且具有良好的可扩展性和可维护性。通过发布通知，应用程序的不同部分可以实时地接收到特定事件的信息，并执行相应的操作。这种模式在事件驱动的系统中非常有用，可以简化系统的设计和开发过程。

Pipeline处理管道

在 MediatR 中，处理管道是一种拦截和处理请求/通知的机制。它允许您在请求/通知到达其处理程序之前或之后执行一系列的中间操作。主要内容包括如下：

处理管道（Pipeline）：处理管道是一个包含一系列中间件（Middleware）的链式结构，用于在请求/通知到达处理程序前后执行预定义的操作。每个中间件都可以对请求/通知进行修改、添加附加逻辑或执行其他相关的任务。
请求管道（Request Pipeline）：请求管道适用于请求处理模式，并且是请求对象经过的处理管道。请求管道中的中间件按照顺序依次执行，直到请求到达最终的请求处理程序为止。每个中间件可以在请求到达处理程序前后执行特定的逻辑，例如验证、日志记录、异常处理等。
通知管道（Notification Pipeline）：通知管道适用于通知处理模式，并且是通知对象经过的处理管道。通知管道中的中间件按照顺序依次执行，直到通知到达所有对应的通知处理程序为止。每个中间件可以在通知到达处理程序前后执行特定的逻辑，例如记录日志、发送通知给其他系统等。
全局管道（Global Pipeline）：MediatR 还提供了全局管道，它是应用于所有请求和通知的通用处理管道。全局管道中的中间件会在每个请求/通知的请求管道或通知管道之前或之后执行，以提供全局级别的处理逻辑，例如安全认证、性能跟踪等。

通过配置处理管道，您可以根据需求对请求和通知进行拦截和修改，以实现各种功能，例如日志记录、验证、缓存、错误处理等。您可以使用 MediatR 提供的扩展点来注册和配置处理管道中的中间件，由中间件按照顺序执行所定义的操作。这样可以使代码具有更高的可复用性、可扩展性和可维护性，并且可以自定义处理管道以满足特定的业务需求

请求预处理

在 MediatR 中，请求预处理是指在请求到达其对应的处理程序之前执行的一系列操作。它允许您在实际的请求处理之前进行一些必要的处理，例如验证请求、修改请求内容、日志记录等。主要内容包括如下：

请求预处理器（Request Pre-Processor）：请求预处理器是一个中间件（Middleware），用于在请求到达其处理程序之前执行特定的操作。它实现了 IPipelineBehavior<TRequest, TResponse> 接口，并通过实现其中的 Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken, RequestHandlerDelegate<TResponse> next) 方法来处理请求。请求预处理器可以对请求对象进行检查、验证、修改或记录日志，然后将请求传递给下一个处理器。
全局请求预处理器（Global Request Pre-Processor）：MediatR 还提供了全局请求预处理器，它是应用于所有请求的通用预处理器。全局请求预处理器通过实现 IPipelineBehavior<TRequest, TResponse> 接口，并在注册和配置时将其应用于所有请求。全局请求预处理器会在每个请求的请求管道中执行，以提供全局级别的处理逻辑。

通过使用请求预处理器，您可以在实际的请求处理之前执行各种操作，例如验证请求的有效性、身份验证、数据转换、异常处理等。这样可以将与请求相关的一些常见任务集中处理，并使请求处理程序更专注于实际的业务逻辑。您可以在应用程序的配置中注册和配置请求预处理器，由 MediatR 自动将其应用于相应的请求上。

请注意，请求预处理器是可选的，具体是否使用取决于您的需求和应用程序的设计。您可以根据需要选择性地添加、配置和使用请求预处理器，以满足特定的业务需求。

异常处理

在 MediatR 中，可以使用异常处理器来处理在请求或通知的处理过程中产生的异常。异常处理器允许您捕获和处理异常，并采取适当的措施，例如记录日志、发送警报、返回特定的错误响应等。主要内容包括如下：

异常处理器（Exception Handler）：异常处理器是一个中间件（Middleware），用于在请求或通知的处理过程中捕获和处理异常。它实现了 IExceptionAction<TRequest, TResponse, TException> 接口，并通过实现其中的 Task<TResponse> Handle(TRequest request, TException exception, CancellationToken cancellationToken, ExceptionHandlerDelegate<TResponse> next) 方法来处理异常。异常处理器可以根据具体的异常类型执行适当的操作，例如记录日志、发送警报或返回错误响应。
全局异常处理器（Global Exception Handler）：MediatR 还提供了全局异常处理器，它是应用于所有请求和通知的通用异常处理器。全局异常处理器通过实现 IExceptionAction<TRequest, TResponse, TException> 接口，并在注册和配置时将其应用于所有请求和通知。全局异常处理器会在每个请求和通知的处理过程中进行异常捕获和处理，以提供统一的异常处理逻辑。

通过使用异常处理器，您可以在请求或通知处理过程中捕获并处理异常，以确保应用程序的稳定性和可靠性。您可以根据具体的异常类型执行适当的操作，例如记录日志以便进行故障排查、发送警报以便及时响应问题、返回特定的错误响应以便通知客户端等。异常处理器也提供了对异常进行自定义处理的灵活性，因此您可以根据需要定义不同的异常处理逻辑。

请注意，异常处理器是可选的，具体是否使用取决于您的需求和应用程序的设计。您可以根据需要选择性地添加、配置和使用异常处理器，以满足特定的业务需求，并确保在处理过程中能够妥善处理可能出现的异常情况

中介器生命周期

在 MediatR 中，中介器（Mediator）的生命周期由容器（Container）管理。具体的生命周期取决于您选择的容器类型，常见的容器包括 ASP.NET Core、Autofac、SimpleInjector 等。

在 ASP.NET Core 中，默认情况下，MediatR 中介器的生命周期与请求的生命周期一致，即每个请求都会创建一个新的中介器实例，并在处理请求期间使用该实例。这种短暂的生命周期确保了每个请求都有自己的中介器实例，以避免请求之间的干扰和状态共享问题。当请求处理完成后，中介器实例将被销毁。

使用其他容器时，可以根据自己的需求配置中介器的生命周期。例如，在 Autofac 容器中，可以通过设置注册类型的生命周期选项来控制中介器的生命周期。常见的生命周期选项包括 Transient（瞬态）、Scoped（作用域）和 Singleton（单例）。瞬态生命周期将为每个解析请求创建一个新的中介器实例，作用域生命周期将在每个作用域内共享同一个中介器实例，而单例生命周期将在整个应用程序生命周期内共享同一个中介器实例。

需要注意的是，在单例生命周期中，中介器实例将被共享并可能导致状态共享的问题。因此，在设计中介器时，应尽量避免依赖和修改中介器实例的状态，以确保每个请求的独立性和可重现性。

总结来说，MediatR 中介器的生命周期取决于所使用的容器类型和配置。默认情况下，在 ASP.NET Core 中介器的生命周期与请求的生命周期一致，而在其他容器中可以根据需要进行配置。无论使用哪种生命周期，都需要注意避免中介器实例之间的状态共享问题，以确保每个请求的独立性和可靠性。

MediatR 适用场景

MediatR 是一个用于实现中介者模式的库，它提供了一种将请求和通知处理解耦的方式，适用于各种场景。以下是 MediatR 的一些适用场景：

CQRS（Command and Query Responsibility Segregation，命令查询责任分离）：MediatR 可以用于实现 CQRS 架构的命令与查询分离。通过将命令和查询封装为不同的请求对象，并使用中介者模式来处理这些请求，可以更好地组织和管理复杂的业务逻辑。
事件驱动架构（Event-Driven Architecture）：MediatR 可以用于实现事件的发布和订阅模式。通过定义和处理事件通知，可以实现松耦合的组件间通信，以及更灵活的系统扩展和异步处理。
插件化和扩展性：MediatR 可以用于实现插件化和可扩展的应用程序架构。通过定义通用的请求和处理逻辑，并利用中介者模式将请求和处理解耦，可以方便地添加、移除和替换各种功能模块。
视图模型更新（View Model Updates）：MediatR 可以用于处理视图模型的更新操作。通过定义更新请求和相应的处理器，可以实现对视图模型的增、删、改等操作，并在更新完成后及时通知相关组件进行界面更新。
领域事件和领域命令：MediatR 可以用于处理领域事件和领域命令。通过定义相应的事件和命令，并使用中介者模式进行处理，可以有效地组织和管理领域逻辑，并实现解耦、可测试和可扩展的领域模型。

总体而言，MediatR 适用于需要解耦请求和处理逻辑的场景，能够提高代码的可读性、可维护性和可扩展性。它可以与其他架构模式（如CQRS、事件驱动架构等）结合使用，以满足不同的业务需求和系统设计要求。

MediatR 的优缺点

MediatR 是一个强大的中介者模式库，具有以下优点和缺点：

优点：

解耦和组织：MediatR 通过将请求和处理逻辑解耦，使用中介者模式将它们组织起来。这种解耦可以使代码更加模块化、可读性更好，也更易于测试和维护。
灵活性和扩展性：MediatR 提供了一种灵活的架构，可以轻松地添加、移除和替换各种处理器。这使得应用程序更具扩展性，可以根据业务需求进行定制化开发。
提高复用性：通过将请求和处理过程分离，MediatR 促进了代码的复用。可以将相同的请求用于不同的处理器，并且能够在不影响其他部分的情况下对处理器进行修改和替换。
适用多种架构模式：MediatR 可以与多种架构模式（如CQRS、事件驱动架构等）结合使用，以满足不同的业务需求和系统设计要求。

缺点：

增加复杂性：使用 MediatR 会引入一定的复杂性。配置和定义请求/处理器需要额外的工作，可能会增加开发和维护的工作量。此外，需要确保正确地使用 MediatR，否则可能导致过多的中介者和处理器，使代码难以理解和维护。
性能开销：由于 MediatR 采用了中介者模式，并且需要通过该中介者传递请求和处理器之间的消息，可能会引入一些性能开销。在大规模和高并发的应用程序中，可能需要对性能进行优化和调整。
学习成本：MediatR 是一个功能强大的库，但也需要一定的学习成本来理解其概念、API和最佳实践。对于团队成员来说，需要投入时间和精力来学习和熟悉 MediatR 的用法和设计思想。

总体来说，MediatR 所带来的好处远远超过了其缺点，但在使用之前需要仔细考虑项目需求和技术栈是否适合使用 MediatR，以及是否值得增加复杂性和性能开销来获得其优势。

MediatR 案例示例

下面是一个使用 MediatR 的 ASP.NET Core 示例，展示了如何在应用程序中处理多个请求和使用管道：

首先，确保您的项目中已经安装了 MediatR 和相关的 NuGet 包。可以使用以下命令来安装它们：

dotnet add package MediatRdotnet add package MediatR.Extensions.Microsoft.DependencyInjection

接下来，打开 Startup.cs 文件，在 ConfigureServices 方法中添加以下代码来配置 MediatR 和相关的依赖注入：

在上述代码中，我们使用 AddMediatR 方法将 MediatR 注册到 DI 容器中。通过传递
Assembly.GetExecutingAssembly()，MediatR 将会扫描当前程序集中的所有请求和处理器。

接下来，我们创建一些请求和处理器来演示多个请求的处理。

首先，我们创建一个简单的请求 HelloWorldRequest 和对应的处理器 HelloWorldHandler：

using MediatR;using System.Threading;using System.Threading.Tasks;public class HelloWorldRequest : IRequest<string>{     // 请求的属性和数据    // ...}public class HelloWorldHandler : IRequestHandler<HelloWorldRequest, string>{     public Task<string> Handle(HelloWorldRequest request, CancellationToken cancellationToken)    {         // 处理请求并返回结果        string result = "Hello, World!";        return Task.FromResult(result);    }}

然后，我们创建另一个请求 GreetUserRequest 和对应的处理器 GreetUserHandler：

using MediatR;using System.Threading;using System.Threading.Tasks;public class GreetUserRequest : IRequest<string>{     public string UserName {  get; set; }}public class GreetUserHandler : IRequestHandler<GreetUserRequest, string>{     public Task<string> Handle(GreetUserRequest request, CancellationToken cancellationToken)    {         // 处理请求并返回结果        string result = $"Hello, { request.UserName}!";        return Task.FromResult(result);    }}

在上述代码中，GreetUserRequest 是一个带有 UserName 属性的请求类，GreetUserHandler 是处理 GreetUserRequest 请求的处理器。

接下来，在控制器中使用 MediatR 组合多个请求和处理器：

using MediatR;using Microsoft.AspNetCore.Mvc;using System.Threading.Tasks;[ApiController]public class HelloWorldController : ControllerBase{     private readonly IMediator _mediator;    public HelloWorldController(IMediator mediator)    {         _mediator = mediator;    }    [HttpGet("/hello")]    public async Task<IActionResult> SayHello()    {         var helloRequest = new HelloWorldRequest();        var greetUserRequest = new GreetUserRequest        {             UserName = "John"        };        // 使用 MediatR 发送多个请求并获取结果        string helloResult = await _mediator.Send(helloRequest);        string greetUserResult = await _mediator.Send(greetUserRequest);        return Ok(new {  Hello = helloResult, GreetUser = greetUserResult });    }}

在上述代码中，我们在 SayHello 方法中创建了一个 HelloWorldRequest 请求和一个 GreetUserRequest 请求，然后使用 MediatR 的 _mediator 对象来发送这两个请求，并获取结果。最后，将结果返回给客户端。