为什么要使用 MediatR 的 3 个理由和 1 个不使用它的原因

https://codeopinion.com/why-use-mediatr-3-reasons-why-and-1-reason-not/

来自 Jimmy Bogard 的 MediatR 库在过去的几年中，正在变得难以置信地流行，它也确实值的这样受到欢迎。它对自己的定义是：简单、平凡的 .NET 中介者模式的实现。那为什么那么多的开发者使用它呢？为什么你也应该使用 MediatR? 这里给出你至少需要考虑使用它的 3 个理由，还有一个为什么你不应该使用它的理由。

什么是 MediatR？

对于不熟悉 MdeidatR 或者不熟悉中介者模式的人来说：

对于软件开发人员来说，中介者模式定义了一个封装一组对象相互交互的对象。该模式是属于行为模式的一种，因为它可以扩展程序运行的行为。

原因 1: 解藕

多数演示 MediatR 的示例使用 ASP.NET Core，但是这并不意味着这是它创建价值的仅有框架。关键是从顶层的框架代码中解藕你的应用代码，而不用关心代码是否真正负责执行你的代码。

这里有一个使用 ASP.NET Core MVC 的示例。

关键点是创建一个请求对象，将它传递给 MediatR，由 MediatR 负责调用针对该请求对象的正确的处理器。

而这里的 PlaceOrderHandler 下单处理器对象完全不需要饮用任何类型或者 ASP.NET Core 的 API。

原因 2: 应用程序请求

至于为什么从顶层框架解藕，例如与 ASP.NET Core 解藕的重要性，问一下自己：我正在创建的是一个应用程序，还是一个 Web 应用程序？

这里的区别是：Web 应用程序是应用程序的一种。

应用程序可以有多种不同的输入。不是所有的请求都通过 HTTP 来实现。这里可能有多种方式与你的应用程序交互。

例如，你可能有需要重复执行的任务，在日常中的特定时间处理特定的操作。或者你可能存在通过消息中间件中抽取特定的消息来触发的任务。

在你的系统中，存在着通过各种方式来调用程序的行为，而不仅仅是通过 HTTP 请求。

在上面的 ASP.NET Core 示例中，我们将来自 HTTP 的请求最终转换成为一个应用程序请求对象。该应用程序请求对象完全从系统的顶级框架中解藕，从而可以在任何地方使用该对象。

使用 MediatR 来创建应用程序请求对象就可以跨越集成边界。

原因 3: 请求处理管线

一旦你能够通过应用程序请求对象来考虑问题，你就可以通过这些请求对象来深入考虑创建请求处理管线。

如果你熟悉 ASP.NET Core 的中间件的话，你会知道它的目的是定义 HTTP 请求的处理管线。

你还可以通过 MediatR 来创建同样的概念。有几种不同的方式可以创建它，这里介绍一种实现 IPipelineBehavior 的示例。

当调用 mediator.Send() 的时候，在调用你的基础处理器处理 (PlaceOrderHander) 之前。 RequestHandlerDelegate 负责调用 PlaceOrderHandler。这就使得我们可以在真正的处理之前切入处理，甚至可以短路而完全不调用它。比如说存在输入数据验证问题的时候。

这就意味着你可以创建任意数目的前置处理器，或者在执行实际行为之后的后置处理器。

它难以置信的强大，支持你可以从你的应用程序请求中分离各种关注点。

为什么不使用它？

不使用 MediatR 的原因很简单，就是所有的处理都是进程内的。这意味着当调用 mediator.Send() 的时候，处理请求的相关处理器也是在同样的进程中执行。

NServiceBus 的作者 Udi Dahan 在我的响应下提出这个问题：

您认为驱使人们从基于 MediatR 的解决方案转向利用进程外消息传递的解决方案的痛点/动机是什么？

进程外的动机将是库功能中的所有附加构建（重试/失败/等）。更快地使用收到的 msg 响应到调用方（不是已处理）。

你有没有发现，在人们开始不使用进程内处理的时候，会因为没有这些东西而感到痛苦？如果是这样，根据你的经验，他们的旅程在多大程度上表现出来？

事件，最大触发器转移到进程外，我猜，在进程内，尽管每个处理程序都是独立的，但异常可能会使整个初始请求失败链失败（取决于异常处理）。一旦你感受到那种痛苦，我会说这就是转折点

用更简单的话来说，您希望每个事件处理程序独立执行

由于所有的处理都是进程内，这对于 Events/Notification (MediatR 称它们为 Nofifications ) 变得显而易见

对于 Notification 来说，它可以拥有 0 到多个处理器。不过，所有的的 Notification 处理器都是在相同的进程中执行的。

在上面的示例中，如果你将一个 Notification 推入到 MediatR 中，这里有 3 个处理器处理该 Notification。它将会执行全部 3 个处理。不过，如果其中一个抛出了异常，会发生什么呢？

该异常会冒泡到你通过 MediatR 发布消息的地方。你将会如何处理它呢？你会重新发布该消息，以便在重新执行的时候成功执行它？如果任务之一是发送邮件呢？

你希望在隔离状态下执行事件处理。这就是转而使用进程外消息的时刻。

在这种场景下，你可能希望看一下 NServiceBus, Brighter, MassTransit, Rebus。