77

以前可能有人问过，但我什至在官方网站上都找不到为什么我应该使用 MediatR 以及它解决了哪些问题？

  • 是因为我可以在构造函数中传递单个对象而不是多个接口吗？

  • 它是 ServicesBus 等的替代品还是竞争对手...

  • 基本上有什么好处，它解决了什么问题

我想购买它，但我不清楚为什么要使用它。

非常感谢

4

2 回答 2

90

是因为我可以在构造函数中传递单个对象而不是多个接口吗？

不。

它是 ServicesBus 等的替代品还是竞争对手...

不。

基本上有什么好处，它解决了什么问题

除此之外，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库

更新

有线输入对此有一些很好的实际评论

MediatR 所做的只是服务定位请求的处理程序。那不是中介模式。在这种情况下，“中介”没有描述两个对象如何通信，它使用已经在应用程序中使用的控制反转，只是提供了一个无用的抽象层，只会使应用程序更难推理为所有的。您已经通过使用带有 IoC 的标准构造函数注入来实现解耦。我不明白为什么人们会买这个。让我们创建多个复合根，这样我们就不必将接口放入构造函数中。

和

OP 完全有理由质疑 MediatR 的观点。我听到的对该问题的最高回答涉及解释中介者模式的一般用途，或者它使调用代码更清晰。前一种解释假设 MediatR 库实际上实现了中介者模式，这还很不清楚。后者不是在已经抽象的 IoC 容器之上添加另一个抽象的理由，这会创建多个复合根。只需注入处理程序而不是服务定位它

于 2018-06-03T05:23:29.347 回答
10

它只是实现业务逻辑组件之间通信的一种方式。

想象一下，你有：

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 库。你可以阅读中介者模式并自己实现一个。

于 2019-02-18T12:48:53.163 回答