MediatR何时以及为何要使用它？vs 2017 webapi

Question

它可能是之前被问过,但我甚至在官方网站上找不到为什么我应该使用MediatR以及它解决了什么问题？

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

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

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

我想购买它,但我不清楚为什么我应该使用它.

非常感谢

Answer 1

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

没有.

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

没有.

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

除此之外,MediatR试图解决的问题之一是你的MVC控制器中的DI Constructor Explosion

public DashboardController(
    ICustomerRepository customerRepository,
    IOrderService orderService,
    ICustomerHistoryRepository historyRepository,
    IOrderRepository orderRepository,
    IProductRespoitory productRespoitory,
    IRelatedProductsRepository relatedProductsRepository,
    ISupportService supportService,
    ILog logger
    )  

这是一个备受争议的话题,并没有一个通用的解决方案,请看一下这个问题

如何避免依赖注入构造函数的疯狂？

如果你想隐藏更多抽象背后的依赖关系,那么此时你需要看看所有的选项,比如重构,分离关注点或其他技术.

老实说,MediatR网站上给出的示例问题和解决方案有点可疑,但确实有它的用途.简而言之,您需要选择适合您和您的环境的最新信息.

中介模式概述

中介是一个对象,它决定对象如何以及何时相互交互.它封装了"how"并根据状态,调用方式或提供给它的有效负载来协调执行.

在你的问题的精神的regaruds应该真的看看这个网站.

通过MediatR简化开发和分离问题

MediatR是一个中介模式的开源实现,它不会尝试做太多而且不会产生魔法.它允许您使用同步或异步模式撰写消息,创建和侦听事件.它有助于减少耦合并隔离请求完成工作的问题并创建调度工作的处理程序.

更多关于Mediator Pattern的信息

您可以在自己的意见中描述为什么要使用它

介体模式通过介体(它是一个东西)通过通信帮助解耦您的应用程序.

通常程序由大量类组成.但是,随着更多类被添加到程序中,这些类之间的通信问题可能变得更加复杂.这使得程序更难以阅读和维护.此外,更改程序可能变得困难,因为任何更改都可能影响其他几个类中的代码.

使用中介模式,对象之间的通信将封装在中介对象中.对象不再直接相互通信(解耦),而是通过中介进行通信.这减少了通信对象之间的依赖性,从而减少了耦合.

在现代软件中,中介模式通常在许多框架中找到,但是您可以创建自己的模式,或者使用许多可用模式中的一个.

从这里,我认为你应该做更多的研究,我的意思是通常你在研究它们之前就知道你需要这些东西,但是在这种情况下,我认为你真的需要找到一些很好的例子来了解你是否想要Mediator Pattern ,甚至更多的MediatR库

更新

wired_in对此有一些很好的实用评论

所有MediatR都是服务定位请求的处理程序.那不是中介模式.在这个例子中,"mediator"没有描述两个对象如何通信,它使用已经在应用程序中使用的控制的反转,并且仅提供一个无用的抽象层,仅用于使应用程序更难以推理为整个.您已经通过使用标准构造函数注入IoC实现了解耦.我不明白为什么人们会买这个.让我们创建多个复合根,这样我们就不必在构造函数中放置接口了.

和

在询问MediatR的观点时,OP是完全合理的.我听到的问题的最高回答涉及解释一般使用中介模式,或者它使调用代码更清晰.前面的解释假设MediatR库实际上实现了中介模式,这远非明确.后者不是在已经抽象的IoC容器之上添加另一个抽象的理由,它创建了多个复合根.只需注入处理程序而不是服务定位它

Answer 2

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

想象一下您有：

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库。您可以阅读有关介体模式的信息，并自己实现。