DAO modello di progettazione e di utilizzarlo su più tavoli

Question

Sto cercando un feedback sul modello Data Access Object design e usarlo quando si deve accedere ai dati su più tavoli. Sembra che quel pattern, che ha un DAO per ogni tabella insieme a un DTO (Data Transfer Object) che rappresenta una singola riga, non sia troppo utile per i dati provenienti da più tabelle. Stavo pensando di creare un DAO composito e un DTO corrispondente che restituirebbe il risultato di, diciamo, eseguendo un join su due tabelle. In questo modo posso utilizzare SQL per acquisire tutti i dati invece di acquisire prima i dati da uno utilizzando un DAO e dalla seconda tabella utilizzando il secondo DAO e poi componendoli insieme in Java.

C'è una soluzione migliore? E no, al momento non sono in grado di spostarmi su Hibernate o su un altro strumento ORM. Semplicemente JDBC per questo progetto.

Answer 1

Sono d'accordo con il vostro approccio. I miei DAO tendono ad essere allineati più a livello di oggetto, piuttosto che da una prospettiva di tabella DB. Posso gestire più di un oggetto tramite un DAO, ma molto probabilmente saranno strettamente correlati. Non c'è motivo per non avere SQL che accede a due tabelle che vivono in un DAO.

E per la cronaca, ho bandito l'acronimo DTO dal mio vocabolario e codice.

Answer 2

Idealmente, come memorizzare i dati in un database, e poi come vi si accede, deve essere derivato dalla natura del rapporto tra le entità di dominio nel modello di dominio. Cioè, il modello relazionale dovrebbe seguire dal modello di dominio. Ad esempio, se hai due entità, ad esempio, Utente e Indirizzo.

Scenario n. 1: gli indirizzi non sono mai accessibili indipendentemente, sono sempre un attributo dell'utente. In questo caso, l'indirizzo è un oggetto valore e l'utente è un'entità e ci sono delle guide su come memorizzare questa relazione. Un modo è quello di memorizzare gli attributi Address of Address accanto agli attributi di User, in una singola tabella. In questo caso, UserDao gestirà entrambi gli oggetti.

Scenario n. 2: l'indirizzo può essere associato a un utente, ma può anche essere separato per conto proprio, un'entità. In questo caso, è necessario un approccio diverso dal primo. Si può avere un DAO separato e una tabella per il tipo di indirizzo.

Il mio punto è, che il più delle volte questa importante idea viene ignorato che Domain Model dovrebbe essere il cuore dell'applicazione, la guida di altri strati.

Ad esempio, se il modello di dominio è definito correttamente e si è ben consapevoli del tipo di entità che si hanno e della relazione tra loro, allora la persistenza (le tabelle relazionali e le loro relazioni, i DAO, ecc.) Si evolveranno come una conseguenza molto logica di ciò che si ha nel modello di dominio.

In altre parole, se si spende un po 'di tempo a studiare il vostro modello, si sarà in grado di tracciare il vostro problema nel determinare come organizzare i tuoi DAO ad un posto nel modello di dominio. Se puoi definire chiaramente il tipo di oggetti e la natura della relazione tra loro nel modello di dominio, ti aiuterà a risolvere il tuo problema nel livello DAL.