OnAfterCreateAsync sur les Collections

[thomaf]

On a le besoin dans le cas où on notifie RabbitMq lors de la création d'une entité.
Si on fait cette notification directement dans le CreateAsync, on a des cas où le message est traité avant que l'entité ne soit créée en base.

[nfaugout-lucca]

Il faut plutôt faire ça dans l'AppController que sur la collection, car comme tu dis la collection est agnostic du SaveChanges là où c'est l'AppController qui le provoque.

@Poltuu a dû faire ce genre de séquençage dans l'AppController sur PTalent, pour les notifs par mail notamment. C'est le même genre d'idée.

[Poltuu]

je confirme ce que @nfaugout a dit, c'est une problématique de synchronisation, qui a lieu au niveau applicatif.
Il faut overrider un XXXAppController, la méthode .Create
Tu auras accès au
await _unitOfWork.SaveChangesAsync();
et donc tu pourras mettre ton code au bon endroit (en dessous)

Mais u simple override, avec ajout de code à la suite de la méthode de base devrait faire l'affaire je pense

[rducom]

Sinon tu peux implémenter un IOnSaveChangesHookAsync<T> qui sera appelé après chaque sauvegarde d'une entité

https://github.com/LuccaSA/RestDrivenDomain/blob/master/src/Rdd.Infra/Storage/IOnSaveChangesAsync.cs

[nfaugout-lucca]

@thomaf la solution via AppController c'est la solution "fonctionnelle", où tu sais dans quel contexte tu te situes. La solution de @rducom c'est une solution "technique" qui va jouer qq soit le contexte qui a provoqué un SaveChanges, à toi de voir dans quel cas tu te trouves, mais je pense que si y'a du RMQ derrière tu dois être sur du fonctionnel.

[thomaf]

Dans mon processus métier, la création d'une ReportRequest implique la publication d'une notification au RemotTaskPublisher.
Je m'attends donc à trouver ce code dans mon domaine.
Le principe du OnAfterCreateAsync est bien d'être agnostique de l'enregistrement au même titre que le OnAfterUpdateEntity.
Après, je ne suis pas sûr de bien saisir la répartition des rôles entre le domaine et l'application.

[rducom]

Avec IOnSaveChangesHookAsync<T> tu aura la liste des entités T modifiées, crées, et supprimées pour n'importe quel appel à SaveChanges. Donc comme dit nico, si systématiquement pour T tu veux faire un truc, alors IOnSaveChangesHookAsync<T> est fait pour toi.

Si par contre, sur certaines méthodes tu veux faire un truc lors d'un crud sur T, et dans d'autres non, alors il faut implémenter toi même ces traitements.

[nfaugout-lucca]

Ici il faut imaginer que l'AppController fait partie de ton Domain.

Le Domain (au sens du projet Domain) ne décide pas quand il peut commiter en base, c'est un choix qu'on a fait. Peut-être à remettre en cause dans une discussion séparée...

Ici c'est un peu la même chose, ce n'est pas le Domain qui peut décider de lever un événement vers le monde extérieur, c'est la responsabilité du AppController au même titre que le commit en base.

Donc ton appController va orchestrer le processus :

• demande au Domain de créer l'entité
• commit en base
• publier un message vers ton publisher, voire déléguer ça au domain, càd appeler une méthode du domain qui publie, ainsi TOUT le code est bien dans le domain, seul l'ordonnancement est délégué à l'appController.