MediatR何时以及为何应使用它? vs 2017 webapi [英] MediatR when and why I should use it? vs 2017 webapi

问题描述

以前可能有人问过，但是即使在官方网站上也找不到为什么我应该使用MediatR以及它解决了什么问题?

It might have been asked before but I cannot find even in the official site why I should use MediatR and what problems it solves?

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

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

它是ServicesBus等的替代者还是竞争对手?

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

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

Basically what are the benefit and what problem does it solve

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

I want to buy into it but its not clear to me why I should use it.

非常感谢

推荐答案

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

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

否.

它是ServicesBus等的替代者还是竞争对手?

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

否.

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

Basically what are the benefit and what problem does it solve

---

MediatR 试图解决的问题之一是 MVC控制器

---

Among other things, one of the problem MediatR is trying to solve is DI Constructor Explosion in your MVC controllers

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

这是一个备受争议的话题，没有一个万能的解决方案，请看一下这个问题

This is a highly debated topic and there is no one-size-fits-all solution, take a look at this question

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

如果您想将依赖项隐藏在更多抽象的后面，那么此时，您将要看一看所有选项，例如重构，更多地分离关注点或其他技术.

If you want to hide dependencies behind even more abstractions, then at this point you will want to take a look at all the options, like refactoring, separating concerns a little more, or other techniques.

老实说， MediatR 网站上给出的示例问题和解决方案有点让人怀疑，但确实有其用途.简而言之，您需要选择适合您和您的环境的东西.

In all honesty, the example problem and solution given on the MediatR website is a little suspect, however it does have its uses. In short, you need to choose whats right for you and your environment.

介体模式概述

介体是一个对象，它决定对象之间如何以及何时相互交互.它封装了如何"并根据状态，调用方式或您为其提供的有效负载来协调执行.

A mediator is an object that makes decisions on how and when objects interact with each other. It encapsulates the "how" and coordinates execution based on state, the way it’s invoked or the payload you provide to it.

关于您的提问的精神，您应该真正看看这个网站:

In regards to the spirit of your question, you should really have a look at this site:

简化MediatR开发和分离问题

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

介体模式通过介体(通过一个东西).

The mediator pattern helps decoupling your application via communication through a mediator (its a thing) .

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

Usually a program is made up of a large number of classes. However, as more classes are added to a program, the problem of communication between these classes may become more complex. This makes the program harder to read and maintain. Furthermore, it can become difficult to change the program, since any change may affect code in several other classes.

使用中介者模式，对象之间的通信被封装在中介者对象中.对象不再彼此直接通信(解耦)，而是通过调解器进行通信.这样可以减少通信对象之间的依赖性，从而减少耦合.

With the mediator pattern, communication between objects is encapsulated within a mediator object. Objects no longer communicate directly with each other (decoupling), but instead communicate through the mediator. This reduces the dependencies between communicating objects, thereby reducing coupling.

在现代软件中，调解器模式通常在许多框架中都可以找到，但是您可以创建自己的框架，也可以使用许多可用的框架中的一种.

In modern software, the mediator pattern is usually found within many frameworks, however you can create your own, or use one of many that are available.

从这里开始，我认为您可能应该做更多的研究，通常是您在研究它们之前先确定需要这些东西，但是在这种情况下，我认为您确实需要找到一些很好的例子来了解您是否想要中介模式，甚至更多的 MediatR 库

From here, i think you should probably just do more research, i mean usually you figure out you need these things before you research them, however in this case i think you really need to find some good examples to know whether you want the Mediator Pattern, and even more The MediatR library

更新

wired_in 对此有一些实用的评论

wired_in had some great practical comment on this

MediatR所做的只是在服务中找到请求的处理程序.那是 不是调解人模​​式.在这种情况下，调解员"不会 描述两个对象如何通信，它使用控制反转 已经在应用程序中使用了，只是提供了 无用的抽象层，仅用于创建应用程序 整体上很难推理.您已经通过以下方式实现了解耦 在IoC中使用标准的构造函数注入.我不明白为什么 人们对此表示认同.让我们创建多个复合根，就像这样 不必将接口放入我们的构造函数中.

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.

和

在质疑MediatR的观点时，OP是完全有道理的. 我对这个问题的回答最多，是解释使用 通常是调解者模式，或者是调解者代码 清洁工.前面的解释假定MediatR库 实际上实现了中介者模式，目前还不清楚.这 后者不是在其上添加另一个抽象的理由 一个已经抽象的IoC容器，它创建了多个复合 根.只需注入处理程序，而不是通过服务定位

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

这篇关于MediatR何时以及为何应使用它? vs 2017 webapi的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！