以前可能有人问过，但我什至在官方网站上都找不到我为什么要使用 MediatR 以及它解决了哪些问题？
是因为我可以在构造函数中传递单个对象而不是多个接口吗？
是ServiceBus等的替代品还是竞争对手...
基本上有什么好处，解决了什么问题
我想购买它，但我不清楚为什么要使用它。
非常感谢
【问题讨论】：
标签： c# asp.net-core-webapi architectural-patterns
是不是因为我可以在构造函数中传递单个对象而不是 多个接口？
没有。
是 ServicesBus 等的替代品还是竞争对手...
没有。
基本上有什么好处，解决了什么问题
除其他外，MediatR 试图解决的问题之一是 MVC 控制器中的 DI 构造函数爆炸
public DashboardController(
ICustomerRepository customerRepository,
IOrderService orderService,
ICustomerHistoryRepository historyRepository,
IOrderRepository orderRepository,
IProductRespoitory productRespoitory,
IRelatedProductsRepository relatedProductsRepository,
ISupportService supportService,
ILog logger
)
这是一个备受争议的话题，没有万能的解决方案，看看这个问题
How to avoid Dependency Injection constructor madness?
如果您想将依赖项隐藏在更多抽象之后，那么此时您将需要查看所有选项，例如重构、更多地分离关注点或其他技术。
老实说，MediatR 网站上给出的示例问题和解决方案有点可疑，但它确实有其用途。简而言之，您需要选择适合您和您的环境的产品。
中介者模式概述
中介者是一个对象，它决定对象如何以及何时相互交互。它封装了“如何”并根据状态、调用方式或您提供给它的负载来协调执行。
关于你的问题的精神，你真的应该看看这个网站：
Simplifying Development and Separating Concerns with MediatR
MediatR 是中介者模式的开源实现，它 不会尝试做太多事情，也不会施展魔法。它允许您 编写消息，使用同步或创建和监听事件 异步模式。它有助于减少耦合和隔离 请求完成工作和创建处理程序的担忧 分派工作。
更多关于中介者模式
你能以你自己的观点描述你为什么要使用它
中介者模式通过中介者的通信帮助decoupling您的应用程序（它是一个东西）。
通常一个程序由大量的类组成。然而，随着更多的类被添加到程序中，这些类之间的通信问题可能会变得更加复杂。这使得程序更难阅读和维护。此外，更改程序可能会变得很困难，因为任何更改都可能影响其他几个类中的代码。
使用中介者模式，对象之间的通信被封装在中介者对象中。对象不再直接相互通信（解耦），而是通过中介进行通信。这减少了通信对象之间的依赖关系，从而减少了耦合。
在现代软件中，中介者模式通常存在于许多框架中，但您可以创建自己的框架，或使用众多可用框架中的一种。
从这里开始，我认为你可能应该做更多的研究，我的意思是通常你在研究它们之前就知道你需要这些东西，但是在这种情况下，我认为你真的需要找到一些好的例子来知道你是否想要中介者模式，甚至更多 MediatR 库
更新
wired_in对此有一些非常实用的评论
MediatR 所做的只是服务定位请求的处理程序。那是 不是中介模式。在这种情况下，“调解人”不 描述两个对象如何通信，它使用控制反转 已经在应用程序中使用，只是提供了一个 无用的抽象层，仅用于制作应用程序 整体上更难推理。您已经通过以下方式实现了解耦 使用带有 IoC 的标准构造函数注入。我不明白为什么 人们对此买账。让我们创建多个复合根，这样我们 不必将接口放入我们的构造函数中。
和
OP 完全有理由质疑 MediatR 的观点。 我听到的对该问题的最高回答涉及解释使用 一般的中介者模式，或者它使调用代码 清洁器。前一种解释假设 MediatR 库 实际上实现了中介者模式，这还不是很清楚。这 后者不是在其之上添加另一个抽象的理由 一个已经抽象的 IoC 容器，它创建了多个复合 根。只需注入处理程序而不是服务定位它
【讨论】：
Open Close Principle 的情况下为所有处理程序提供一些附加行为非常有用。审计就是一个例子。如果您需要添加这样的行为，您必须提前完成，或者作为一种更好的方法，您可以打开一扇门稍后添加它，而无需任何Shotgun Surgery 并更改工作代码。只是不要忘记保持请求和响应不可变。这会让你对代码进行推理。
这只是实现业务逻辑组件之间通信的一种方式。
想象一下你有：
FirstRequest // which handled by FirstRequestHandler(FirstRequest)
SecondRequest // which handled by SecondRequestHandler(SecondRequest)
ThirdRequest // which handled by ThirdRequestHandler(ThirdRequest)
...有数百个...
然后是 ComplexRequest，此时 ComplexResponse 必须是 FirstResponse 和 ThirdResponse 的组合。
我们应该如何解决这个问题？
嗯，ComplexRequestHandler 必须注入 FirstHandler 和 ThirdHandler，获取它们的结果，然后组合它们。
但为什么 ComplexRequestHandler 应该有权访问 FirstRequestHandler 接口？ 为什么我们要费心将 First, Third ... OneHundredAndTwentythHandler 注入 ComplexHandler 中？
MediatR 在这种用例中为我们提供的是第三方告诉我们： “给我一个请求，我会给你正确的回应，相信我！”
所以 ComplexHandler 对第一和第三处理程序一无所知。 它只知道所需的请求和响应（通常只是包装 DTO）。
注意：您不必为此使用 MediatR 库。你可以阅读中介者模式并自己实现一个。
【讨论】：