NServiceBus,NHibernate和GuidComb() [英] NServiceBus, NHibernate, and GuidComb()

查看:87
本文介绍了NServiceBus,NHibernate和GuidComb()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

免责声明:这是来自我有关NServiceBus的其他问题的后续问题

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?

用户通过填写​​带有相关详细信息的表格在网站上进行注册.当用户单击表单上的提交"按钮时,Web应用程序将获取表单数据并创建一条消息,并使用NServiceBus和Bus.Send()将其发送到应用程序层.应用程序层负责创建新用户并发布已创建该用户的事件(Bus.Publish()),以便其他进程可以完成其工作(向新用户发送电子邮件,将该用户添加到搜索索引中)等等).

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).

现在,由于这种情况下的Web应用程序完全依赖于应用程序层来创建新的用户实例,因此它如何了解用户的ID?如果在这种情况下不使用NServiceBus,而是让网站向DAL发出进程内调用,则我将使用NHibernate的GuidComb()策略为新用户创建标识符,然后再将新行保留在数据库.如果接收到用于创建新用户的命令的消息处理程序应用程序(在当前情况下)使用相同的策略,则如何将userId传达回Web应用程序?

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?

推荐答案

您可以随意提供一个ID用作关联标识符,只需将其放入Web应用程序的消息中,即可随消息发起的任何过程一起携带.

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.

这样,如果只有他们记得提供相关ID,则可以将请求与系统中的其他事件相关联.

That way, you can correlate the request with other events around your system, if only they remember to supply the correlation ID.

但这听起来像是您希望在同一Web请求中将您的用户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?

这篇关于NServiceBus,NHibernate和GuidComb()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆