是因为我可以在构造函数中传递单个对象而不是
大量的接口？
No.
它是 ServicesBus 等的替代品还是竞争对手...
No.
基本上有什么好处以及解决什么问题
除其他事项外，其中一个问题是MediatR正在尝试解决的是DI 构造函数爆炸在你的MVC 控制器
public DashboardController(
ICustomerRepository customerRepository,
IOrderService orderService,
ICustomerHistoryRepository historyRepository,
IOrderRepository orderRepository,
IProductRespoitory productRespoitory,
IRelatedProductsRepository relatedProductsRepository,
ISupportService supportService,
ILog logger
)
这是一个备受争议的话题，没有一刀切的解决方案，看看这个问题
如何避免依赖注入构造函数的疯狂？ https://stackoverflow.com/questions/2420193/how-to-avoid-dependency-injection-constructor-madness
如果您想将依赖关系隐藏在更多抽象背后，那么此时您将需要查看所有选项，例如重构、进一步分离关注点或其他技术。
老实说，示例问题和解决方案给出了MediatR网站有点可疑，但它确实有它的用途。简而言之，您需要选择适合您和您的环境的内容。
中介者模式概述
中介者是一个对象，它决定对象之间如何以及何时交互。它封装了“如何”并根据状态、调用方式或您提供给它的有效负载来协调执行。
关于你的问题的精神，你真的应该看看这个网站：
使用 MediatR 简化开发并分离关注点 https://web.archive.org/web/20190118110711/https://blogs.msdn.microsoft.com/cdndevs/2016/01/26/simplifying-development-and-separating-concerns-with-mediatr/
MediatR 是中介者模式的开源实现
不会尝试做太多事情，也不会施展魔法。它可以让你
使用同步或
异步模式。它有助于减少耦合并隔离
请求完成工作和创建处理程序的问题
分派工作。
有关中介者模式的更多信息
您能以您自己的观点描述一下为什么要使用它吗
中介模式有帮助解耦 https://en.wikipedia.org/wiki/Coupling_(computer_programming)您的应用程序通过中介者（它是一个东西）进行通信。
通常一个程序是由大量的类组成的。然而，随着程序中添加更多的类，这些类之间的通信问题可能会变得更加复杂。这使得程序更难阅读和维护。此外，更改程序可能会变得困难，因为任何更改都可能影响其他几个类中的代码。
使用中介者模式，对象之间的通信被封装在中介者对象中。对象之间不再直接通信（解耦），而是通过中介者进行通信。这减少了通信对象之间的依赖性，从而减少了耦合。
在现代软件中，中介者模式通常存在于许多框架中，但是您可以创建自己的框架，或使用许多可用的框架之一。
从这里开始，我认为你可能应该做更多的研究，我的意思是通常你在研究它们之前就会弄清楚你需要这些东西，但是在这种情况下，我认为你真的需要找到一些很好的例子来知道你是否想要中介者模式，甚至更多MediatR library
Update
wired_in对此有一些非常实用的评论
MediatR 所做的只是为请求查找处理程序。那是
不是中介模式。在这种情况下，“调解人”并不
描述两个对象如何通信，它使用控制反转
已经在应用程序中使用并且仅提供
无用的抽象层，仅用于创建应用程序
更难从整体上进行推理。您已经通过以下方式实现了解耦
使用 IoC 的标准构造函数注入。我不明白为什么
人们对此表示认同。让我们创建多个复合根，这样我们
不必将接口放入我们的构造函数中。
and
OP 质疑 MediatR 的观点是完全合理的。
我听到的对该问题的最常见回答涉及解释
一般的中介者模式，或者它使调用代码
清洁工。前一种解释假设 MediatR 库
实际上实现了中介者模式，这一点还很不清楚。这
后者并不是在之上添加另一个抽象的理由
一个已经抽象的 IoC 容器，它创建多个组合
根。只需注入处理程序而不是服务定位它
