Impostazione creata e aggiornata nelle entità JPA automaticamente

Question

Sto lavorando a un'applicazione web JPA (implementazione di Hibernate), Spring e Stripes. Ho un numero di entità JPA che hanno i seguenti campi in comune sia per la verifica che per le query:

createdBy - l'ID utente della persona che ha creato l'entità. createdOn - data l'entità è stato creato UpdatedBy - l'ID utente della persona che ha aggiornato l'ultima volta l'entità updatedOn - data l'entità dell'ultimo aggiornamento

ho ottenuto il mio app di lavoro in modo che createdOn e updatedOn sono impostato automaticamente quando l'entità è persistente, ma non sono sicuro di come posso ottenere i campi createdBy e updatedBy popolati senza dover passare l'ID utente attualmente connesso dalla classe controller fino ai DAO.

Qualcuno ha qualche suggerimento su come potrei fare questo senza passare userid dappertutto? Si noti che l'ID utente corrente è memorizzato nell'oggetto HttpSession al momento, quindi il mio back-end deve in qualche modo accedere a questi dati ...

Grazie!

Answer 1

Ho deciso che un ThreadLocal è probabilmente il modo più pulito per farlo nella mia applicazione.

Answer 2

Si può avere uno sguardo a uno di questi approcci per passare l'ID utente come contesto nel livello di business:

• How To Pass Context Between Layers With ThreadLocal And EJB 3
• How To Pass Context In Standard Way - Without ThreadLocal

(I post può ancora essere rilevante Anche se non stai usando EJB, il secondo post ha senso solo se usi Spring con JTA)

Personalmente, scoraggiavo questi approccio, come io percepisco due problema con esso:

• Testabilità: dati di contesto dovrà essere istituito nel test
• Contratto: dati contestuali partecipano nel contratto di utilizzare l'entità, ma non è chiaramente visibile l'interfaccia.

Passare userID "dappertutto" può sembrare un grosso lavoro, ma penso che sia più pulito.

Per impostare la data e l'ID utente automaticamente quando l'entità viene creata o aggiornata, è possibile utilizzare uno EntityListener or lifecycle callbacks (forse lo state già facendo). Speranza che aiuta ...

Answer 3

mi piacerebbe creare una classe come questa:

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

    //getters and setters 

Le classi di entità che hanno il requisito che hai descritto sarebbe semplicemente estendere questa classe, che ci si regolerà variabili nel livello necessario (controller ad esempio) e non è necessario preoccuparsi fino in fondo nei DAO.