NServiceBus、NHibernate 和 GuidComb()
免责声明：这是我关于 NServiceBus 的其他问题 这是 回答得很彻底。
我当前的问题是：如果一个网站被构建为像上面提到的文章那样“愚蠢”的网站，那么以下场景如何工作？
用户通过填写包含相关详细信息的表格在网站上注册。当用户单击表单上的“提交”按钮时，Web 应用程序将获取表单数据并创建一条消息，并使用 NServiceBus 和 Bus.Send() 将其发送到应用程序层。应用程序层负责创建新用户并发布用户已创建的事件 (Bus.Publish())，以便其他进程可以执行其操作（向新用户发送电子邮件、将用户添加到搜索索引）等）。
现在，由于此场景中的 Web 应用程序完全依赖于应用程序层来创建新用户实例，因此它如何了解用户的 ID？如果我在这种情况下没有使用 NServiceBus，而是让网站向 DAL 发出进程内调用，我会使用 NHibernate 的 GuidComb() 策略为新用户创建标识符，然后再将新行保留在数据库。如果接收创建新用户命令的消息处理程序应用程序（在当前场景中）使用相同的策略，则 userId 如何传回 Web 应用程序？
在这种情况下，我是否必须应用不同的策略来管理标识符？
Disclaimer: This is a follow-on question from my other question about NServiceBus which was answered very thoroughly.
My current question is this: If a website is built to be 'dumb' like the article referred to, above, suggests then how does the following scenario work?
A user registers on a website by filling out a form with relevant details. When the user clicks the 'submit' button on the form the web application takes the form data and creates a message which it sends to the application tier using NServiceBus and Bus.Send(). The application tier goes about the business of creating the new user and publishing the event that the user has been created (Bus.Publish()) so that other processes can do their thing (email the new user, add the user to a search index, etc, etc).
Now, since the web application in this scenario relies entirely on the application tier for the creation of the new user instance, how does it get to know about the user's id? If I didn't use NServiceBus in this scenario but, rather, let the website issue an in-process call to a DAL I'd use NHibernate's GuidComb() strategy to create the identifier for the new user before persisting the new row in the database. If the message handler application which receives the command to create a new user (in the current scenario) uses the same strategy, how is the userId communicated back to the web application?
Do I have to apply a different strategy for managing identifiers in a scenario such as this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以随意想出一个 ID 来用作相关标识符，只需将其放入您的Web 应用程序中的消息，允许它被携带在消息启动的任何进程中。
这样，您就可以将请求与系统周围的其他事件关联起来，只要他们记得提供关联 ID。
但听起来您希望在同一个 Web 请求中将您的用户 ID 反馈给您 - 这无法通过异步后端轻松完成，而异步后端正是消息传递为您提供的功能。
创建用户后，向用户发送一封电子邮件，其中包含指向某种网关的（秘密）链接，以恢复用户的会话，这难道不是可以接受的吗？
You're free to come up with an ID to use as a correlation identifier by putting it in your message in the web application, allowing it to be carried around whatevery processes are initiated by the message.
That way, you can correlate the request with other events around your system, if only they remember to supply the correlation ID.
But it sounds like you want your user ID to be fed back to you in the same web request - that cannot easily be done with an asynchronous backend, which is what messaging gives you.
Wouldn't it be acceptable to send an email to the user when the user has been created, containing a (secret) link to some kind of gateway, that resumes the user's session?
UI 不能监听总线上的“用户创建”事件吗？然后，您可以通过让事件包含某种类型的事件 ID 链接回“请求用户创建”事件或与事件中的一些其他众所周知的数据（例如用户名）进行关联。尽管您可能还必须侦听多个事件，例如“用户创建失败”事件。
这与 Web 浏览器中的正常 AJAX 处理没有什么不同。从技术上讲，您不会阻止带外回拨到 Web 服务器。您调用该调用并异步等待回调。
Wouldn't the UI be able to listen to the bus for the "user created" event? And then you could correlate either by having the event include some kind of event ID linking back to the "user creation requested" event or against some other well known data in the event (like the user name). Though you probably also have to listen to multiple events, such as "user creation failure" event.
This is not unlike normal AJAX processing in a web browser. Technically, you don't block on the out of band call back to the web server. You invoke the call and you asynchronously wait for a callback.