# 为什么要使用 MediatR 的 3 个理由和 1 个不使用它的原因
为什么要使用 MediatR 的 3 个理由和 1 个不使用它的原因
来自 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。
冠军
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
