之前可能有人问过，但我甚至在官方网站上也找不到为什么我应该使用 MediatR 以及它解决了什么问题？
-
是因为我可以在我的构造函数中传递单个对象而不是多个接口吗？
-
它是服务总线等的替代品还是竞争对手...
-
基本上有什么好处，它解决了什么问题
我想购买它，但我不清楚为什么我应该使用它。
非常感谢
因为我可以在构造函数中传递单个对象而不是 多种接口？
不。
它是服务总线等的替代品还是竞争对手...
不。
基本上有什么好处，它解决了什么问题
除此之外，MediatR试图解决的问题之一是MVC 控制器中的DI 构造函数爆炸
public DashboardController(
ICustomerRepository customerRepository,
IOrderService orderService,
ICustomerHistoryRepository historyRepository,
IOrderRepository orderRepository,
IProductRespoitory productRespoitory,
IRelatedProductsRepository relatedProductsRepository,
ISupportService supportService,
ILog logger
)
这是一个备受争议的话题，没有一刀切的解决方案，看看这个问题
如何避免依赖注入构造函数的疯狂？
如果你想隐藏更多抽象背后的依赖关系，那么此时你需要看看所有选项，比如重构、多分离关注点或其他技术。
老实说，MediatR网站上给出的示例问题和解决方案有点可疑，但它确实有其用途。简而言之，您需要选择适合您和您的环境的产品。
调解器模式概述
中介器是决定对象如何以及何时相互交互的对象。它封装了"如何"，并根据状态、调用方式或您提供给它的有效负载来协调执行。
关于你问题的精神，你真的应该看看这个网站：
使用 MediatR 简化开发并分离关注点
MediatR 是中介器模式的开源实现，它 不会尝试做太多，也不会表演魔法。它允许您 撰写消息，使用同步或创建和侦听事件 异步模式。 它有助于减少耦合并隔离 请求完成工作和创建处理程序的问题 调度工作。
有关调解器模式的更多信息
您能用自己的观点描述一下为什么要使用它吗
中介器模式有助于通过调解器进行通信来解耦应用程序(这是一回事)。
通常一个程序由大量的类组成。但是，随着更多的类被添加到程序中，这些类之间的通信问题可能会变得更加复杂。这使得程序更难阅读和维护。此外，更改程序可能会变得困难，因为任何更改都可能影响其他几个类中的代码。
使用中介器模式，对象之间的通信封装在中介器对象中。对象不再直接相互通信(解耦)，而是通过中介器进行通信。这减少了通信对象之间的依赖关系，从而减少了耦合。
在现代软件中，调解器模式通常存在于许多框架中，但是您可以创建自己的模式，或使用许多可用的框架之一。
从这里开始，我认为您可能应该做更多的研究，我的意思是通常您在研究它们之前会弄清楚您需要这些东西，但是在这种情况下，我认为您真的需要找到一些很好的例子来了解您是否需要调解器模式，甚至更多MediatR库
更新
wired_in对此有一些很好的实际评论
MediatR 所做的只是服务定位请求的处理程序。那是 不是调解器模式。在这种情况下，"调解人"没有 描述两个对象如何通信，它使用控制反转 已经在应用程序中使用，并且仅提供 无用的抽象层，仅用于制作应用程序 整体上更难推理。您已经通过以下方式实现了解耦 将标准构造函数注入与 IoC 结合使用。我不明白为什么 人们买账。让我们创建多个复合根，以便我们不必将接口放在我们的构造函数中。
和
OP完全有理由质疑MediatR的观点。 我对这个问题听到的最高回答涉及解释使用 一般的中介模式，或者它发出调用代码 清洁工。前一种解释假设 MediatR 库 实际上实现了调解器模式，这还远未明确。这 后者不是在 一个已经抽象的 IoC 容器，它创建多个复合 根。只需注入处理程序而不是服务定位它
它只是实现业务逻辑组件之间通信的一种方式。
想象一下，您有：
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 接口？ 为什么我们应该费心注入第一，第三...一百和第二十处理程序进入我们的复杂处理程序？
MediatR在这样的用例中给我们的是第三方告诉我们： "给我一个请求，我会给你正确的回应，相信我！">
所以 ComplexHandler 对 First Handlers 和 Third Handlers 一无所知。 它只知道所需的请求和响应(通常只是包装 DTO)。
注意：您不必为此使用 MediatR 库。您可以阅读有关调解器模式的信息并自行实现一个。