Configuration NServiceBus端点名称如何与发布/订阅一起使用

今天一整天，我都在和NServiceBus打同样的简单问题。问题是有很多关于如何更改配置的文档，但几乎没有任何文档可以帮助我了解我需要的配置

有一些示例应用程序，它们是可以工作的，但是没有解释它们是如何工作的，它们有什么限制，或者如何做一些与示例稍有不同的事情。示例应用程序还提供了“Hello world”类型的简单性，在任何实际应用程序中，您都需要与示例应用程序不同的东西，但同样，对于如何进行这些更改或配置选择的含义没有帮助

从文档中很难猜到的所有事情来看，目前最令人沮丧的是端点名称、UnicastBusConfig映射和发布/订阅持久性之间的关系

端点名称是否为MSMQ队列的名称？这是否意味着对于所有消息类型，每个应用程序只有一个输入队列？在UnicastBusConfig中添加映射是否会导致向发布服务器发送订阅消息，还是会在订阅数据库中添加订阅记录？为什么不能将同一消息类型多次添加到UnicastBusConfig？为什么我不能订阅某种类型的邮件而不必知道它们来自哪个服务器

---

对于理解NServiceBus的人来说，这似乎很简单，不值得记录，但对于第一次了解这一点的人来说，这是最难从低级细节的泥沼中推断出来的非常简单的东西。

你可能想在，它相当全面，应该能回答你的大部分问题

端点名称是否为MSMQ队列的名称

对

这是否意味着对于所有消息类型，每个应用程序只有一个输入队列

对。每个端点都有一个与之关联的队列，因此该端点的所有消息都通过相同的队列

在UnicastBusConfig中添加映射是否会导致向发布服务器发送订阅消息，还是会在订阅数据库中添加订阅记录

都不是。UnicastBusConfig部分用于设置类型（或程序集）和端点之间的关系。因此，它实际上不会导致建立订阅（本身），但它会告诉框架消息将来自何处（以及如何订阅它们）

当系统启动且NSB找到与UnicastBusConfig中的节匹配的特定类型消息的处理程序时，将创建实际订阅（假设已启用自动订阅）

这也适用于发送命令——配置部分让框架知道将命令发送到哪个端点（）

为什么不能将同一消息类型多次添加到UnicastBusConfig

因为命令只能有一个（逻辑）端点来处理它，而事件只能有一个（逻辑）端点来发布它

为什么我不能订阅某种类型的邮件而不必知道它们来自哪个服务器

这个问题更难确定地回答，因为它涉及到中央代理（中心辐射式）与总线式体系结构的哲学

---

但简而言之，某处需要知道如何找到出版商才能订阅它。由于NServiceBus没有中央代理或路由表，因此由客户机根据其使用的端点的知识进行配置。

这就是您要寻找的吗？我花了一天的大部分时间阅读此文档并尝试代码。这就是我在最初的问题中提到的“细节沼泽”。文档中的问题是，每篇文章都假设您已经阅读了其他每一篇文章，这意味着您必须反复阅读，逐步建立上下文，并逐渐理解更多内容，我只是想了解一些基本的原则，这些原则可以很容易地在介绍或入门类文章中涵盖。我一直在为同样的事情而挣扎。我也在与Azure集成，所以我感觉到了你的痛苦。这似乎是一个非常普遍的问题。库和服务通常会描述一些非常高级的抽象概念，然后在堆栈的最底层对数千个单独的方法进行大量的详细描述，但是缺少关于这些数千个小片段如何实现高级概念的任何文档。谢谢，这非常有帮助。不幸的是，我认为这意味着NServiceBus不是适合我的解决方案，也许这就是为什么我对它感到如此沮丧的原因。请随意在邮件列表上发表意见——与您的特定情况进行反复的对话可能会使您受益匪浅。