Creazione / aggiornamento della strategia di salvataggio dell'entità

4

Nota: anche se sto parlando di Java in questa domanda, quello che sto chiedendo qui dovrebbe davvero essere indipendente dalla lingua.

Mi sto dilettando in OR / M per la prima volta e ho preparato la seguente " strategia di aggiornamento " per tutte le mie entità:

  • Tutti i POJO di entità estendono una classe di base astratta BaseEntity che ha una proprietà Long id , per l'ID univoco / la chiave primaria
  • Le applicazioni sono libere di creare istanze di un'entità, ma tutti i metodi costruttori / factory omettono l'impostazione di questa proprietà id
  • Quindi se Person extends BaseEntity , allora posso scrivere Person p = new Person(...) ma p.getId() è NULL.
  • Solo quando chiami il metodo DAO dell'entità, l'entità viene salvata nella persistenza e gli viene assegnato un id .
  • I miei DAO avranno solo un metodo creazionale save* (come savePerson(Person) ) e eseguiranno un controllo per il fatto che id è NULL o no per determinare se dovremmo provare a INSERT una nuova entità registra, o UPDATE un record di entità esistente.
  • I miei metodi DAO save* restituiranno sempre un'istanza dell'entità appena creata / aggiornata, ma assicureranno che la id sia ora impostata correttamente (se non lo era prima).

Per me è logico / ragionevole, ma sembra un po 'complicato / contorto. Sto andando in questo modo nel modo sbagliato, ci sono i migliori " update patterns " per OR / M che si occupano di questo per me? All'inizio pensavo di fare tutto in JDBC non elaborato e poi di migrare ad Hibernate una volta che mi trovassi a mio agio.

    
posta smeeb 08.12.2014 - 18:39
fonte

1 risposta

0

Sembra / sembra buono, vorrei solo offrire questi suggerimenti:

  1. Potrebbe voler includere un timestamp in BaseEntity per risolvere i conflitti. Ad esempio, cosa succede se due persone stanno modificando il record allo stesso tempo. È quindi possibile sviluppare una strategia di risoluzione dei conflitti basata su questo valore (ultimo in vincite, ecc.)
  2. Idealmente ogni tabella dovrebbe avere una chiave naturale per verificare l'unicità. Ma la chiave surrogata funziona bene. Tieni presente che se si tratta di una chiave surrogata, dovrebbe sempre provenire dalla tua applicazione, non dal cliente o dal chiamante. Non aspettarti che le informazioni dal client o dal chiamante siano sempre accurate. È qui che aiutano le chiavi naturali.
risposta data 08.12.2014 - 19:58
fonte

Leggi altre domande sui tag