NServiceBus, NHibernate и GuidComb ()

Question

Отказ от ответственности: Это дополнительный вопрос от моего другого вопроса о NServiceBus , на который был дан очень подробный ответ .

Мой текущий вопрос такой: ЕслиВеб-сайт создан так, чтобы быть «тупым», как в статье, упомянутой выше, и затем предлагается, как работает следующий сценарий?

Пользователь регистрируется на веб-сайте, заполняя форму с соответствующими подробностями.Когда пользователь нажимает кнопку «отправить» в форме, веб-приложение получает данные формы и создает сообщение, которое оно отправляет на уровень приложения, используя NServiceBus и Bus.Send ().Уровень приложения связан с созданием нового пользователя и публикацией события, в котором он был создан (Bus.Publish ()), чтобы другие процессы могли делать свое дело (отправка нового пользователя по электронной почте, добавление пользователя в поисковый индекс).и т. д.).

Теперь, поскольку веб-приложение в этом сценарии полностью полагается на уровень приложения для создания нового пользовательского экземпляра, как оно узнает об идентификаторе пользователя?Если бы я не использовал NServiceBus в этом сценарии, а вместо этого позволил бы веб-сайту вызывать внутрипроцессный вызов DAL, я бы использовал стратегию NHidBenid GuidComb () для создания идентификатора для нового пользователя перед сохранением новой строки вбаза данных.Если приложение-обработчик сообщений, которое получает команду для создания нового пользователя (в текущем сценарии), использует ту же стратегию, как идентификатор пользователя передается обратно в веб-приложение?

Нужно ли применять другую стратегиюдля управления идентификаторами в сценарии, подобном этому?

Answer 1

Вы можете придумать идентификатор для использования в качестве идентификатора корреляции , поместив его в свое сообщение в веб-приложении, позволяя передавать его во время любых процессов, инициируемых сообщением.

Таким образом, вы можете сопоставить запрос с другими событиями в вашей системе, если только они не забудут предоставить идентификатор корреляции.

Но звучит так, будто вы хотите, чтобы ваш идентификатор пользователя был возвращен вам в том же веб-запросе - что не может быть легко сделано с помощью асинхронного бэкэнда, что дает вам обмен сообщениями.

Разве было бы неприемлемо отправлять пользователю электронное письмо после его создания, содержащее (секретную) ссылку на какой-либо шлюз, который возобновляет сеанс пользователя?

Answer 2

Разве пользовательский интерфейс не сможет прослушивать шину для события «пользовательский»? И затем вы можете сопоставить либо наличие в событии какого-либо идентификатора события, связанного с событием «запрошено создание пользователя», либо с некоторыми другими хорошо известными данными в событии (например, именем пользователя). Хотя вам, вероятно, также придется прослушивать несколько событий, таких как событие «сбой при создании пользователя».

Это мало чем отличается от обычной обработки AJAX в веб-браузере. Технически, вы не блокируете обратный звонок на веб-сервер. Вы вызываете вызов и асинхронно ждете обратного вызова.