NServiceBus、NHibernate 和 GuidComb()

Question

免责声明：这是来自my other question about NServiceBus 的后续问题answered very thoroughly。

我目前的问题是：如果一个网站被构建为像上面提到的文章那样“愚蠢”，那么下面的场景是如何工作的？

用户通过填写​​包含相关详细信息的表单在网站上注册。当用户单击表单上的“提交”按钮时，Web 应用程序获取表单数据并创建一条消息，它使用 NServiceBus 和 Bus.Send() 将其发送到应用程序层。应用层负责创建新用户并发布用户已创建的事件（Bus.Publish()），以便其他进程可以做他们的事情（给新用户发送电子邮件，将用户添加到搜索索引等）。

现在，由于本场景中的 Web 应用程序完全依赖应用程序层来创建新的用户实例，它如何知道用户的 id？如果在这种情况下我没有使用 NServiceBus，而是让网站发出对 DAL 的进程内调用，我将使用 NHibernate 的 GuidComb() 策略为新用户创建标识符，然后再将新行保留在数据库。如果接收到创建新用户的命令的消息处理程序应用程序（在当前场景中）使用相同的策略，那么 userId 是如何传回 Web 应用程序的？

在这种情况下，我是否必须采用不同的策略来管理标识符？

Answer 1

您可以随意想出一个 ID 用作correlation identifier，只需将其放入 Web 应用程序的消息中，即可在消息启动的任何进程中携带它。

这样，您可以将请求与系统周围的其他事件关联起来，前提是它们记得提供关联 ID。

但听起来您希望您的用户 ID在同一个 Web 请求中反馈给您 - 这不能通过异步后端轻松完成，而这正是消息传递给您的。 p>

是否可以在创建用户后向用户发送一封电子邮件，其中包含指向某种网关的（秘密）链接，以恢复用户的会话？

Answer 2

UI 不能为“用户创建”事件监听总线吗？然后，您可以通过让事件包含某种事件 ID 链接回“用户创建请求”事件或与事件中的一些其他众所周知的数据（如用户名）进行关联。尽管您可能还必须监听多个事件，例如“用户创建失败”事件。

这与 Web 浏览器中的正常 AJAX 处理没有什么不同。从技术上讲，您不会阻止对 Web 服务器的带外回呼。您调用调用并异步等待回调。