Utilizzo di DAO con gli oggetti compositi

Question

Sto cercando di riscrivere un gruppo di DAO qui è l'impostazione:

• solo pianura JDBC (senza JPA, ORM di sorta)
• nessuna interfaccia utilizzata
• un sacco di controlli prima di inserire un oggetto
• oggetti commerciali sono fortemente legati

mia domanda principale è: Come faccio Persi st/recuperare un oggetto business che è composto da più altri oggetti? ad es. il mio CustomerDAO conosce AddressDAO e recupera gli indirizzi di csutomers da lì?

Answer 1

solo pianura JDBC (senza JPA, ORM di sorta) oggetti commerciali sono fortemente legati

Non certo perché non si desidera utilizzare JPA mentre si desidera che gli oggetti di business per essere collegate, ma almeno dovresti usare il modello JDBC di Spring che ti libererebbe da qualche codice standard.

Per quanto riguarda gli altri vincoli, lo farei come segue:

1. Vorrei ancora impiegare interfacce per definire i DAO metodi e la loro attuazione in un modello di primavera JDBC sostenuta DAOImpl. Utilizzare il DAO ovunque e iniettare DAOImpl.
2. I miei DAO saranno semplicemente mappatura uno-a-uno alle tabelle sottostanti e ciascun DAO non saprebbe dell'esistenza di altri DAO.
3. Il mio livello Manager avrà tutta la logica aziendale che esegue controlli di convalida e prepara l'insieme di oggetti che devono essere persistenti, chiama il DAO appropriato e il metodo appropriato (CREATE/UPDATE/DELETE) per mantenere gli oggetti.
4. Anche in questo caso, il livello Manager seguirà l'implementazione basata su interfaccia e il livello di visualizzazione avrà i tipi di gestore iniettati con ManagerImpls.

I miei due centesimi!

Answer 2

Si può prendere in considerazione l'utilizzo di JOOQ. Non è JPA, ma può essere facilmente utilizzato come soluzione alternativa. È abbastanza leggero Fornisce inoltre uno strumento di reverse engineering, in cui crea le entità del database come oggetti DAO.

Ho incorporato JOOQ in una situazione rilevante, in cui l'applicazione è stata progettata in modo equo. Non ho usato la sua funzionalità DAO, piuttosto che usarlo come livello superiore per evitare di fare scherzi con JDBC Layer.

Cheers!

Answer 3

Le entità composite sono uno strato sopra i DAO. Se si desidera rimuovere TUTTO l'accoppiamento, gli oggetti di dominio persistenti da DAO dovrebbero essere piatti senza relazioni. Vedi i modelli Core J2EE CompositeEntity.

Inoltre, è una buona idea non introdurre l'accoppiamento tra i DAO mettendo i cercatori per uno nell'altro. Es .:

IndirizzoDAO.findForCustomerId (id);

è inferiore all'utilizzo di un terzo DAO per gestire la relazione. I.E:

CustomerAddressRelDAO.findAddressForCustomer (id);

Se si utilizza una relazione DAO, né l'indirizzo né il cliente dipendono (o ne sono consapevoli) reciprocamente.