之前可能会被问到但是我甚至在官方网站上找不到为什么我应该使用MediatR以及它解决了什么问题？
是因为我可以在构造函数中传递单个对象而不是多个接口？
它是ServicesBus等的替代品还是竞争对手......
基本上有什么好处，它解决了什么问题
我想购买但我不清楚为什么要使用它。
非常感谢答案 0 :(得分：47)
是因为我可以在构造函数中传递单个对象而不是 多种接口？
没有
它是ServicesBus等的替代品还是竞争对手......
没有
基本上有什么好处，它解决了什么问题
除此之外， MediatR 试图解决的问题之一是 MVC控制器中 DI Constructor Explosion
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 网站上提供的示例问题和解决方案有点可疑，但确实有其用途。简而言之，您需要为您和您的环境选择最新的。
介体模式概述
介体是一个对象，可以决定对象如何以及何时相互交互。它封装了“how”并根据状态，调用方式或提供给它的有效负载来协调执行。
关于你的问题的精神，你应该看看这个网站：
Simplifying Development and Separating Concerns with MediatR
MediatR是中介模式的开源实现 不会试图做太多而且没有魔法。它允许你 使用同步或组合撰写消息，创建和侦听事件 异步模式。它有助于减少耦合并隔离 请求完成工作和创建处理程序的问题 派遣工作。
有关Mediator Pattern的更多信息
您可以在自己的意见中描述为什么要使用它
介体模式通过介体（它的一个东西）通过沟通帮助decoupling你的应用程序。
通常程序由大量类组成。但是，随着更多类被添加到程序中，这些类之间的通信问题可能变得更加复杂。这使得程序更难以阅读和维护。此外，更改程序可能会变得很困难，因为任何更改都可能会影响其他几个类中的代码。
使用中介模式，对象之间的通信将封装在中介对象中。对象不再直接相互通信（解耦），而是通过中介进行通信。这减少了通信对象之间的依赖关系，从而减少了耦合。
在现代软件中，中介模式通常位于许多框架中，但您可以创建自己的模式，也可以使用许多可用模式中的一种。
从这里开始，我认为你应该做更多的研究，我的意思是通常你在研究它们之前就知道你需要这些东西，但是在这种情况下，我认为你真的需要找到一些很好的例子来了解你是否想要介体模式，甚至更多 MediatR 库
<强>更新
wired_in 对此有一些很好的实用评论
所有MediatR都是服务找到请求的处理程序。那是 不是中介模式。在这种情况下，“调解员”没有 描述两个对象如何通信，它使用控制反转 已经在应用程序中使用，只是提供了一个 无用的抽象层，只用于创建应用程序 更难以整体推理。你已经实现了脱钩 使用标准构造函数注入IoC。我不明白为什么 人们买进这个。让我们创建多个复合根 不必在我们的构造函数中放置接口。
和
在质疑MediatR的观点时，OP是完全合理的。 我听到的问题的最高回应涉及解释使用 通常是中介模式，或者它是调用代码 清洁器。前面的解释假定MediatR库 实际上实现了中介模式，这远远不清楚。该 后者不是在上面添加另一个抽象的理由 一个已经抽象的IoC容器，它创建了多个复合 根。只需注入处理程序而不是服务定位它
答案 1 :(得分：1)
这只是在业务逻辑组件之间实现通信的一种方式。
想象一下您拥有：
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库。您可以阅读有关介体模式的信息，并自己实现。