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

Closed. This question is opinion-based。它当前不接受答案。
                            
                        
                    
                
                            
                                
                
                        
                            
                        
                    
                        
                            想改善这个问题吗？更新问题，以便editing this post用事实和引用来回答。
                        
                        6年前关闭。
                                                                                            
                
        
我想听听您对最近几天困扰我的一个问题的看法。

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

我认为这是耦合的不良示例。

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

我认为.NET的经典方法更好-该类应在其与.NET事件处理程序的接口中定义一个事件，并且任何希望使用此事件处理程序的观察者都应订阅它。

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

这也引发了一个大问题。

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

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

我很高兴听到您对这个问题的想法。

盖伊

最佳答案

这并不是一个很好的SO问题。它可能已关闭。无论您有什么疑问，IServiceBus的表面积都非常小。您可以根据需要轻松更换它。如果实现Consumes.*接口，则消费者之间的耦合度更高。但是您只需将消费者注册为代表，就没有关系了。最终结果应该是减少系统的整体耦合。

最后，您使用服务总线，因此无需担心消息传输或传递。尽管有时内部流程通信并不是真正的问题-将来很容易分崩离析。

关于c# - 有关在.NET中使用消息队列服务总线的问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/18266758/