Service layer vs DAO - Perché entrambi?

Generalmente il DAO è il più leggero possibile ed esiste esclusivamente per fornire una connessione al DB, a volte astratto in modo che possano essere utilizzati diversi backend DB.

Il livello di servizio è lì per fornire la logica per operare sui dati inviati ae da DAO e dal client. Molto spesso questi 2 pezzi saranno raggruppati nello stesso modulo, e occasionalmente nello stesso codice, ma li vedrete comunque come entità logiche distinte.

Un altro motivo è la sicurezza: se fornisci un livello di servizio che non ha alcuna relazione con il DB, è più difficile ottenere l'accesso al DB dal client se non attraverso il servizio. Se non è possibile accedere al DB direttamente dal client (e non c'è un modulo DAO banale che agisca come servizio), allora tutto ciò che un utente malintenzionato può subire è tentare di hackerare il livello del servizio prima che ottenga tutto tranne il accesso più igienizzato ai tuoi dati.

Sono lo scrittore del post in questione. Ho la mia giusta parte di lavorare su diverse tecnologie e diverse architetture. Sulla base di quanto detto sopra, posso tranquillamente dire che avere un livello di servizio e uno strato dao è sempre una buona idea. DAO dovrebbe essere limitato a solo aggiungere / aggiornare / inserire / selezionare oggetti Entity in / da database e questo è tutto. Se vuoi fare qualcosa in più in termini di logica, aggiungilo al livello di servizio. Ciò contribuirà a rendere il codice modulare e facilmente sostituibile quando il database viene sostituito (per una parte dei dati). Questo è particolarmente applicabile nelle applicazioni che coinvolgono report che hanno logiche pesanti anche dopo aver recuperato i dati dal database.

Inoltre, in primavera, la sicurezza viene applicata a livello di servizio in modo ideale. Non ti piacerebbe cambiare in questo modo.

Adam Bien sottolinea nel suo libro che l'EntityManager JPA è una buona implementazione universale del DAO:

link

Nel mondo Java EE non c'è quasi mai la necessità di scrivere il proprio DAO perché le implementazioni JPA ne includono una. Devi solo scrivere il livello di servizio.

L'implementazione del proprio livello DAO è davvero un post di sbornia dalla pessima architettura J2EE di 15 anni fa, ma molte persone si sentono ancora costrette a farlo. Questi layer DAO personalizzati spesso non forniscono altro che funzioni di inoltro che chiamano il metodo corrispondente su EntityManager.

Quindi per rispondere alla tua domanda, sì hai bisogno di un livello di servizio e di un DAO, ma devi solo scrivere il livello di servizio.

Di solito inserisco tutti i codici db specifici (query) in DAO, nella gestione delle transazioni e nella logica aziendale nei servizi. Ciò consente ai metodi di servizio di invocare metodi su più dao e mantenerli tutti nella stessa transazione. A mio parere, questo consente un migliore riutilizzo del codice in tutto il mondo.

Ho scoperto che il livello di servizio aggiunge complessità non necessaria nella maggior parte dei casi. In teoria è di evitare di avere una logica di business nello strato dao, ma alla fine questo porta solo alla confusione, anche alcune persone non sono state in grado di rimuovere completamente il livello dao in quanto ritengono che non aggiunga valore. link

Ma se hai più logiche di business allora sì, è una buona idea. Quanto è essenziale creare un livello di servizio?

IMHO il livello di servizio può essere considerato come un livello tra il controller e il livello DAO. Questo livello di servizio è esattamente dove possiamo aggiungere la logica aziendale e persino creare un oggetto di ritorno specifico per ciò che deve essere reso dalla vista.