c# - 有关在 .NET 中使用消息队列服务总线的问题

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改进这个问题？更新问题，以便 editing this post 可以用事实和引用来回答它.

8年前关闭。




Improve this question




我想听听您对最近几天困扰我的主题的意见。

在我们的项目中，我们使用 MassTransit 服务总线。我们创建一个
使用 IoC 容器的 IServiceBus(MassTransit 的接口(interface))的单例实例，所有需要此 IServiceBus 的类都在构造函数中获取它。
这导致我们项目中的很多类都获取了IServiceBus作为构造函数参数，这使得它们与MassTransit服务总线耦合在一起，实际上达到了使用消息队列通知的概念。

我认为这是耦合的一个坏例子。

通过将 IServiceBus 传递给各种类，我们定义了该类向外部监听器发送通知的方式，并强制该方式成为面向服务总线的方式。

我认为 .NET 的经典方式更好——该类应该在其接口(interface)中使用 .NET 事件处理程序定义一个事件，并且任何想要使用此事件处理程序的观察者都应该订阅它。

我们以这种方式获得的是，我们不致力于实现具有服务总线的类。这样，服务总线可以成为该类事件处理程序的观察者，并且当该事件发生时，它会引发将一些消息发送到服务总线队列的逻辑。

这也提出了一个大问题。

鉴于项目在单个进程上运行，我们何时以及为什么应该在项目中使用服务总线？

如果项目由多个进程组成，我可以看到优势，因为使用消息队列更容易传递强类型消息，但是当它在一个进程范围内时，我无法理解它的好处。
如果我想让类通知观察者、消费者等，我会在类中引发一个事件，并创建一个单独或封闭的调度程序类组，这些类将订阅我的项目中的所有这些事件，这样我就可以处理消息传输的逻辑。此外，这样添加观察者的逻辑将集中在项目中的一个位置。

我很高兴听到你对这个问题的看法。

盖伊

Answer 1

这不是一个很好的问题。它很可能被关闭。无论您有什么问题，IServiceBus 的表面积很小。如果需要，您可以轻松更换它。如果您实现 Consumes.*，消费者的耦合度会更高。接口(interface)。但是你可以只注册消费者为代表，那就没关系了。最终结果应该是系统的整体耦合更少。

最后，您使用服务总线，因此您无需担心消息传输或传递。虽然有时内部进程通信并不是真正的问题 - 在 future 很容易 split 。