c# - MediatR 何时以及为何我应该使用它？

Question

<分区>

Answer 1

Is it because I can pass a single object in my constructor rather than a multitude of Interfaces?

没有。

Is it a replacement or competitor of ServicesBus etc...

没有。

Basically what are the benefit and what problem does it solve

---

除其他外，MediatR 试图解决的问题之一是MVC Controller 中的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 is an open source implementation of the mediator pattern that doesn’t try to do too much and performs no magic. It allows you to compose messages, create and listen for events using synchronous or asynchronous patterns. It helps to reduce coupling and isolate the concerns of requesting the work to be done and creating the handler that dispatches the work.

关于中介者模式的更多信息

Can you in your own opinion describe why would you use it

中介者模式有帮助 decoupling您的申请通过调解员进行沟通(这是一回事)。

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

借助中介者模式，对象之间的通信被封装在中介者对象中。对象之间不再直接通信(解耦)，而是通过中介进行通信。这减少了通信对象之间的依赖性，从而降低了耦合。

在现代软件中，中介者模式通常存在于许多框架中，但是您可以创建自己的框架，或使用众多可用的框架之一。

从这里开始，我认为你可能应该做更多的研究，我的意思是通常你在研究它们之前弄清楚你需要这些东西，但是在这种情况下我认为你真的需要找到一些好的例子来知道你是否想要中介者模式，甚至更多 MediatR 库

更新

wired_in 对此有一些非常实用的评论

All MediatR does is service locate a handler for a request. That is not the mediator pattern. The "mediator" in this instance, does not describe how two objects communicate, it uses inversion of control that is already being used in an application and just provides a useless layer of abstraction that only serves to make an application harder to reason about as a whole. You already achieve decoupling by using standard constructor injection with IoC. I don't understand why people buy into this. Let's create multiple composite roots just so we don't have to put interfaces in our constructor.

和

The OP is completely justified in questioning the point of MediatR. The top responses I hear to the question involve explaining the use of the mediator pattern in general, or that it makes the calling code cleaner. The former explanation assumes that the MediatR library actually implements the mediator pattern, which is far from clear. The latter is not a justifcation for adding another abstraction on top of an already abstracted IoC container, which creates multiple composite roots. Just inject the handler instead of service locating it