Ci sono dei veri benefici per un livello DAO?

Proverò ad affrontare parte della tua domanda: perché ho bisogno di un layer DAO se non intendo mai scambiare i database?

Poiché un altro rispondente ha menzionato parte del tuo obiettivo quando scrivi una classe è il Principio di Responsabilità Unica: una classe dovrebbe avere solo una ragione per cambiare. In poche parole, non si desidera modificare il codice senza necessità, perché così facendo si introduce il rischio. Per minimizzare tale rischio, cerchiamo di evitare di toccare l'implementazione di una classe per troppe ragioni. Se dovessi modificare la mia classe perché le regole aziendali sono cambiate, o perché ho deciso di cambiare il modo in cui l'ho mappato nella memoria persistente, avrei due motivi per cambiare il mio codice. Rimuovendo una di queste responsabilità, la mappatura del database, posso evitare il rischio di commettere un errore che impatta sull'altro e l'onere del test di controllarle entrambe. Non voglio controllare i miei mapping Db, solo perché cambio una regola aziendale. Potresti anche sentire le persone parlare di "separazione delle preoccupazioni", questo è un altro modo di esprimere questa idea. Una classe che gestisce la mia logica per organizzare i container non dovrebbe preoccuparsi della persistenza.

Entra in gioco anche quando pensiamo al test unitario. Quando collaudo unitamente la mia classe di arrangiamento per container di spedizione, non voglio che quei test siano accoppiati ad altre preoccupazioni, come la persistenza. Voglio essere isolato da loro. Quindi ho bisogno di essere facilmente in grado di testare da solo. Se la mia classe non contiene la logica di persistenza, posso verificarla facilmente in memoria, senza preoccuparmi di come viene mantenuta.

Questo driver produce un ulteriore vantaggio: ragionamento sul nostro codice. Se non eseguiamo l'accesso ai dati in punti casuali del nostro codice, ma accedendo al DAO attraverso un livello del servizio applicativo e quindi all'accesso agli oggetti restituiti da questo, non avrò improvvisamente in esecuzione un codice I / O inaspettato durante l'esecuzione della logica di business. È anche molto più facile ragionare sul nostro codice di persistenza se non è inframmezzato dalla logica aziendale.

Questo rende molto più facile pensare al nostro codice. Possiamo seguire la logica del dominio senza che la nostra comprensione sia inquinata dall'accesso allo storage persistente. Questa capacità di ragionare sul codice facilmente è una chiave per la produttività

La massima espressione di molte di queste idee di stratificazione è un architettura esagonale .

Dovresti essere consapevole che un modello di dominio non è l'ideale per tutti gli scenari; in particolare dove non hai una logica di business. In tal caso uno script di transazione (una cosa dopo l'altra) potrebbe essere la soluzione giusta. Alcuni modelli, come CQRS, esistono per cercare di ottenere i vantaggi di un modello di dominio, senza i costi per un semplice accesso in lettura, ad esempio per la visualizzazione di una pagina Web.

Per come la metti, l'alternativa ad avere un livello DAO non sta avendo un livello DAO. Non avere un livello DAO significa che il codice al livello immediatamente superiore è responsabile della gestione degli aspetti di persistenza a basso livello, che contraddice il principio della responsabilità singola.

Non devi necessariamente usare framework avanzati come Hibernate e Spring. Per piccoli progetti o progetti in cui è abbastanza conveniente pensare ai dati come relazionali, può essere più di una seccatura. Tuttavia, non avere qualsiasi astrazione dell'aspetto di persistenza in un sistema sarebbe un grosso difetto di progettazione.

Dipende da cosa sei disposto a fare con i tuoi DAO e cosa consideri essere un DAO ... Leggi il AnemicDomainModel e capirai che cosa dovrebbe o non dovrebbe fare il tuo livello del modello e, quindi, cosa dovrebbe fare un DAO.

Ad esempio, secondo me e sulla base della mia piccola esperienza, un DAO dovrebbe gestire la gestione delle transazioni (l'ibernazione può farlo per te, quindi implementa i comportamenti DAO per te), anche se stai utilizzando un solo database perché potrebbe non sapere mai quando avresti bisogno di usare un secondo. Un modello (entità) dovrebbe gestire come e dove dovrebbe essere salvato ... Non il problema DAO ... AnemicDomainModel dovrebbe aiutarti.

Il problema sembra derivare dal fatto che Hibernate e soprattutto Spring sono animali terribilmente complessi che fanno molto più di quanto la maggior parte della gente possa desiderare, in particolare in progetti di piccole / medie dimensioni supportati da una singola fonte di dati.

E per risolvere questo problema, basta usare uno strumento diverso, più semplice, invece di abbandonare il concetto nel suo insieme.

Per quanto riguarda i benefici: flessibilità, modularità e separazione delle preoccupazioni. I dati sono gestiti da un codice progettato per fare ciò e nient'altro, e questo ti permette, oltre a cambiare l'archivio dati, di modificare facilmente il modello / schema fornendo la stessa API per codificare nei livelli superiori.