Définition automatique de createdBy et updatedBy dans les entités JPA

Question

Je travaille sur une application web JPA (implémentation de Hibernate), Spring et Stripes. J'ai un certain nombre d'entités JPA qui ont les champs suivants en commun à des fins d'audit et de requête :

createdBy - l'ID utilisateur de la personne qui a créé l'entité. createdOn - la date de création de l'entité updatedBy - ID de l'utilisateur de la personne qui a mis à jour l'entité pour la dernière fois. updatedOn - Date de la dernière mise à jour de l'entité.

Mon application fonctionne de telle sorte que les champs createdOn et updatedOn sont automatiquement définis lorsque l'entité est persistée, mais je ne sais pas comment faire pour remplir les champs createdBy et updatedBy sans devoir passer par l'ID de l'utilisateur actuellement connecté depuis la classe du contrôleur jusqu'aux DAO.

Quelqu'un a-t-il des suggestions sur la façon dont je pourrais faire cela sans passer les userIDs partout ? Notez que l'ID de l'utilisateur actuel est stocké dans l'objet HttpSession pour le moment, donc mon backend doit accéder d'une manière ou d'une autre à ces données...

Merci !

Answer 1

Vous pouvez examiner l'une de ces approches pour transmettre l'ID utilisateur comme contexte dans la couche métier :

• Comment passer le contexte entre les couches avec ThreadLocal et EJB 3 ?
• Comment passer le contexte de manière standard - sans ThreadLocal ?

(Ces articles peuvent être pertinents même si vous n'utilisez pas EJB. Le deuxième post n'a cependant de sens que si vous utilisez Spring avec JTA)

Je décourage personnellement cette approche, car j'y vois deux problèmes :

• Testabilité : les données contextuelles devront être mises en place dans le test.
• Contrat : les données contextuelles participent au contrat d'utilisation de l'entité mais ne sont pas clairement visibles dans l'interface.

Passer le userID "partout" peut sembler être un gros travail, mais je pense que c'est plus propre.

Pour définir automatiquement la date et l'ID utilisateur lors de la création ou de la mise à jour de l'entité, vous pouvez utiliser un fichier de type EntityListener ou callbacks de cycle de vie (peut-être le faites-vous déjà). J'espère que cela vous aidera...

Answer 2

J'ai décidé qu'un ThreadLocal est probablement la façon la plus propre de faire cela dans mon application.

Answer 3

Je créerais une classe comme ça :

@MappedSuperclass
public abstract class AuditableDomainClass {
  private long createdBy;
  private long updatedBy;

  //getters and setters

Vos classes d'entités qui ont les exigences que vous avez décrites pourraient simplement étendre cette classe, vous définiriez vos variables dans la couche dont vous avez besoin (contrôleur par exemple) et vous n'auriez pas besoin de vous en préoccuper jusqu'en bas dans les DAO.