NServiceBus, NHibernate et GuidComb()

Question

Clause de non-responsabilité: Ceci est une question subséquente de my other question about NServiceBus qui était answered very thoroughly.

Ma question actuelle est la suivante: Si un site Web est construit pour être «bête» comme l'article mentionné ci-dessus, suggère alors comment fonctionne le scénario suivant?

Un utilisateur s'inscrit sur un site Web en remplissant un formulaire avec des détails pertinents. Lorsque l'utilisateur clique sur le bouton "Soumettre" dans le formulaire, l'application Web prend les données du formulaire et crée un message qu'il envoie au niveau application en utilisant NServiceBus et Bus.Send(). Le niveau applicatif s'occupe de la création du nouvel utilisateur et de la publication de l'événement que l'utilisateur a créé (Bus.Publish()) afin que les autres processus puissent faire leur travail (envoyer un e-mail au nouvel utilisateur, ajouter l'utilisateur à un index de recherche , etc).

Maintenant, puisque l'application Web de ce scénario repose entièrement sur le niveau de l'application pour la création de la nouvelle instance d'utilisateur, comment est-ce qu'elle apprend à connaître l'ID de l'utilisateur? Si je n'utilisais pas NServiceBus dans ce scénario, mais plutôt que le site Web lance un appel en cours à un DAL, j'utiliserais la stratégie GuidComb() de NHibernate pour créer l'identifiant du nouvel utilisateur avant de conserver la nouvelle ligne dans le base de données. Si l'application du gestionnaire de messages qui reçoit la commande pour créer un nouvel utilisateur (dans le scénario actuel) utilise la même stratégie, comment l'ID utilisateur est-il communiqué à l'application Web? Dois-je appliquer une stratégie différente pour gérer les identifiants dans un scénario comme celui-ci?

Answer 1

Vous êtes libre de trouver un ID à utiliser comme correlation identifier en l'insérant dans votre message dans l'application Web, ce qui permet de l'acheminer quel que soit le processus initié par le message. De cette façon, vous pouvez corréler la demande avec d'autres événements autour de votre système, si seulement ils se souviennent de fournir l'ID de corrélation.

Mais il semble que vous vouliez que votre ID utilisateur vous soit renvoyé dans la même requête Web - ce qui ne peut pas être facilement fait avec un backend asynchrone, qui est ce que la messagerie vous donne.

Ne serait-il pas acceptable d'envoyer un courrier électronique à l'utilisateur lorsque celui-ci a été créé, contenant un lien (secret) vers un type de passerelle, qui reprend la session de l'utilisateur?

Answer 2

L'interface utilisateur ne pourrait-elle pas écouter le bus pour l'événement "utilisateur créé"? Et puis vous pourriez corréler soit en ayant l'événement inclure une sorte d'ID d'événement reliant à l'événement «création d'utilisateur demandé» ou contre d'autres données bien connues dans l'événement (comme le nom d'utilisateur). Bien que vous ayez probablement besoin d'écouter plusieurs événements, tels que l'événement "création d'un utilisateur".

Ceci n'est pas différent du traitement AJAX normal dans un navigateur Web. Techniquement, vous ne bloquez pas sur l'appel hors bande vers le serveur Web. Vous appelez l'appel et vous attendez de manière asynchrone un rappel.