DAO/repository: valore restituito buona pratica dopo l'inserimento/aggiornamento

Question

Anche se probabilmente una domanda banale, mi sono sempre chiesto questo.

In genere, dopo l'inserimento nel db, sembra prassi comune restituire l'id dell'entità aziendale.

@Override 
public Long createUser(UserEntity user) { 
    em.merge(user); 
    em.flush(); 

    return user.getId(); 
} 

Esiste un motivo convincente per restituire l'id invece del riferimento all'oggetto business stesso?

Analogamente, ho visto update restituire void, mentre potrebbe essere un id/utente.

Se dovessi scrivere un DAO/Repository per altri utenti, quale sarebbe il valore restituito consigliato (se presente) e perché?

Answer 1

Perché non restituire l'intera istanza se è stata creata/aggiornata correttamente? La stessa cosa primavera dati fare,

<S extends T> S save(S entity); 
<S extends T> Iterable<S> save(Iterable<S> entities); 

1. Cosa devo fare se ho bisogno di un'altra parte dell'oggetto creato/aggiornato, ad eccezione id? (name, date per l'entità User).

2. Perché restituisce id se ci sono alcuni campi che caratterizzano esattamente un'istanza (una chiave primaria composta)?

Non c'è difficoltà di restituire l'intero oggetto (non c'è nulla di "testa" qui come detto da @Danny Fonk), ma può risparmiare molto tempo in futuro.

Answer 2

Secondo la mia esperienza, nel processo di inserimento restituire l'id all'entità aziendale è una buona pratica perché tale ID potrebbe essere utilizzato completamente per continuare il processo di business in quanto è appena immesso record, inoltre per il processo di aggiornamento si preleva il entità prima di aggiornare il record, quindi non è necessario restituire l'id

Answer 3

Penso anche che restituire l'ID in generale sia buono se non addirittura migliore. Oppure puoi anche restituire l'intero oggetto, ma questo è un po '"overhead" se non hai più bisogno di lavorarci sopra dopo la creazione.

All'aggiornamento/modifica di un oggetto nel database restituiamo sempre l'oggetto stesso o molto probabilmente solo un valore booleano in cui l'aggiornamento è riuscito o meno dal momento che abbiamo già l'oggetto.

Answer 4

Se si restituisce l'entità, il codice del client sarebbe simile a questa:

MyEntity e = ...; 
MyEntity created = dao.create(e); 

ma "e" e "creato" sono lo stesso oggetto. Questo può portare a confusione. Si potrebbe obiettare che in futuro è possibile modificare l'implementazione del metodo di creazione in modo che restituisca effettivamente un'entità diversa. Ho visto questo. Non mi è piaciuto Era imho un terribile design di persistenza.

Ora c'è una situazione in cui ritengo che restituire l'id sia una buona opzione: se si dispone di un limite di transazione (REQUIRES_NEW) attorno al metodo di creazione. Passare id invece di entità attraverso i confini delle transazioni non è una cosa negativa.