Conception gérée par domaine - Suppressions logiques

Question

Donc, j'ai un beau modèle de domaine construit. Les référentiels gèrent l'accès aux données et ce qui ne l'est pas. Une nouvelle configuration est apparue, indiquant que les raisons doivent être consignées avec les suppressions. Jusqu'à présent, les suppressions étaient assez simples = > Entity.Children.Remove (enfant). Aucun suivi de changement interne ne se produisait car mon outil ORM gérait la gestion de l'état. Cependant, je ne sais pas exactement comment gérer cela.

1) Je pouvais conserver une collection d'enfants supprimée dans l'entité parent et extraire le suivi des modifications de nHibernate et le gérer moi-même.

2) ??????

Answer 1

D'accord, cela semble fou et je vais tenter un autre coup, même si je suis peut-être fessée pour une mauvaise utilisation de nHibernate. Avant de supprimer, pourquoi ne sélectionnez-vous pas les enfants à supprimer (leurs identifiants sont-ils corrects?) Et effectuez une transformation en toute entité que vous utiliserez pour consigner vos suppressions dans une table. Ajoutez le motif aux entités et enregistrez-les, puis procédez à vos suppressions. La meilleure partie est que vous pouvez utiliser une entité générique, à savoir "auditInfo". pour le résultat de la transformation, et vous pouvez le faire dans une transaction pour pouvoir tout annuler en cas d'échec! OK, peut-être fou mais créatif non?

Answer 2

Pourriez-vous implémenter les interface IInterceptor et remplacez la fonctionnalité onDelete pour extraire les informations dont vous avez besoin de l'entité et les envoyer à l'enregistreur avant de les supprimer (avec NHibernate bien sûr)?

exemple

Answer 3

Si les suppressions sont relativement rares pour ce type d'entité, j'ajouterais un indicateur à l'entité pour la marquer comme "logiquement" "supprimé". plutôt que de supprimer réellement la ligne. L’application devra alors gérer le masquage de ces entités dans des circonstances normales.

Si cela entraînerait un nombre inacceptable de "périmés". rangées - je suggérerais quelque chose de similaire à la réponse de Watson. En fonction des exigences exactes, vous pourriez probablement vous contenter de consigner les données supprimées et une "raison" supplémentaire. champ quelque part directement à partir de l'application. L’utilisation d’intercepteurs est plus transparente et plus agréable du point de vue de l’audit, mais un journal de suppression séparé (table, base de données, fichier) est probablement plus simple.