我想听听你对过去几天困扰我的话题的看法。
在我们的项目中，我们使用的是MassTransit服务总线。我们创造了一个 使用IoC容器的IServiceBus（MassTransit接口）的单例实例，以及需要此IServiceBus的所有类在构造函数中获取它。 这导致我们项目中的很多类将IServiceBus作为构造函数参数获取，这使得它们与MassTransit服务总线耦合，实际上是使用消息队列的通知概念。
我认为这是耦合的一个坏例子。
通过将IServiceBus传递给各个类，我们定义了这个类应该向外部侦听器发送通知的方式，并强制采用面向服务总线的方式。
我认为.NET的经典方式更好 - 类应该在其接口中使用.NET事件处理程序定义一个事件，并且任何想要使用此事件处理程序的观察者都应该订阅它。
我们以这种方式获得的收益是我们不致力于实施具有服务总线的课程。这样，服务总线就可以成为该类事件处理程序的观察者，当该事件发生时，它会引发逻辑，将一些消息发送到服务总线队列。
这也提出了一个大问题。
我们何时以及为什么要在项目中使用服务总线，因为项目在一个流程上运行？
如果项目由多个进程组成，我可以看到优点，因为使用消息队列传递强类型消息更容易，但我不能理解它在一个进程范围内的好处。 如果我希望类通知观察者，消费者等通知，我会从类中引发一个事件，并创建一个或一组封闭的调度程序类，它们将订阅我项目中的所有这些事件，这样我就可以处理消息传递的逻辑。此外，以这种方式添加观察者的逻辑将集中在项目中的一个位置。
我很高兴听到你对这个问题的看法......
盖伊
答案 0 :(得分：0)
这不是一个很好的问题。它可能会被关闭。无论您的问题是什么，IServiceBus的表面积都很小。如果需要，您可以轻松更换它。如果您实现Consumes.*接口，消费者会更加耦合。但是您可以将消费者注册为代表，然后无关紧要。最终结果应该是系统的整体耦合较小。
最后，您使用服务总线，因此您无需担心邮件传输或传递。虽然有时内部流程沟通并不是真正的问题 - 但未来很容易分裂。