使用.NET中的消息队列服务总线重新分级时出现问题
本文关键字：问题 总线 NET 消息 服务 队列 使用 | 更新日期: 2023-09-27 18:27:50
我想听听你对最近几天困扰我的一个问题的看法。。
在我们的项目中，我们使用MassTransit服务巴士。我们创建使用IoC容器的IServiceBus（MassTransit的接口）的singleton实例，以及所有需要此IServiceBus的类在构造函数中获取它。这导致我们项目中的许多类都将IServiceBus作为构造函数参数，这使它们与MassTransit服务总线耦合，并且实际上与使用消息队列的通知概念耦合。
我认为这是耦合的一个坏例子。
通过将IServiceBus传递给各个类，我们定义了该类向外部侦听器发送通知的方式，并强制该方式为面向服务总线的方式。
我认为.NET的经典方式更好——类应该在其与.NET事件处理程序的接口中定义一个事件，任何想使用该事件处理程序（eventhandler）的观察者都应该订阅它
我们通过这种方式获得的收益是，我们不致力于实现具有服务总线的类。这样，服务总线就可以成为该类事件处理程序的观察器，当该事件发生时，它会引发向服务总线队列发送一些消息的逻辑。
这也提出了一个大问题。。
考虑到项目在单个进程上运行，我们应该在项目中何时以及为什么使用服务总线？
如果项目由几个流程组成，我可以看到优势，因为使用消息队列传递强类型消息更容易，但我无法理解它在一个流程范围内的优势。如果我想让类向观察者、消费者等通知，我会从类中引发一个事件，并创建一个单独或封闭的调度程序类组，订阅我的项目中的所有这些事件，这样我就可以处理消息传输的逻辑。此外，通过这种方式，添加观察者的逻辑将集中在项目中的一个位置。
我很高兴听到你对这个问题的看法。。
Guy
这不是一个很好的SO问题。它可能会关闭。不管你的问题如何，IServiceBus的表面积都很小。如果需要，您可以轻松更换。如果您实现Consumes.*接口，那么消费者会更加耦合。但你可以将消费者注册为代表，那就没关系了。最终的结果应该是，您的系统的整体耦合更少。
最后，你使用服务巴士，这样你就不必担心信息的运输或递送。虽然有时存在内部过程，但沟通并不是一个真正的问题——在未来很容易破裂。