Service layer vs DAO - Perché entrambi?

64

Ho lavorato con SpringMVC, Hibernate e alcuni database in un esempio di applicazione Web Java.

Ce ne sono alcuni diversi che lo fanno, ma questa esercitazione sull'integrazione di Spring 3 e ibernazione con esempio ha una classe di modello, vista (in jsp) e un servizio e classi dao per il controller.

La mia domanda è: entrambe le classi di servizio e DAO non fanno la stessa cosa? Perché avresti bisogno di entrambi?

Questo era il tutorial che stavo effettivamente usando: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

— Jeff
fonte

60

Generalmente il DAO è il più leggero possibile ed esiste esclusivamente per fornire una connessione al DB, a volte astratto in modo da poter utilizzare back-end DB diversi.

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

Un altro motivo è la sicurezza: se si fornisce 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 esiste un modulo DAO banale che funge da servizio), tutto ciò che un utente malintenzionato che ha assunto il controllo del client può fare è tentare di hackerare anche il livello di servizio prima di ottenere tutti tranne il accesso più igienizzato ai tuoi dati.

— gbjbaanb
fonte

1

Sono d'accordo con la separazione dei livelli di servizio e dao e del livello di servizio contenente la logica aziendale.

— Peter Delaney,

per non parlare del fatto che 1 servizio può chiamare diversi DAO, ad esempio quando si salva un utente si può parlare con l'UsDao, l'User OrderDao, ecc. O dovremmo creare un servizio per ciascuno? E poi chi potrebbe chiamare tutti questi servizi?

— Fermin Silva,

40

Sono lo scrittore di posta in questione. Ho avuto la mia giusta dose di lavoro su diverse tecnologie e diverse architetture. Sulla base di quanto sopra, posso tranquillamente dire che avere un livello di servizio e un livello dao è sempre una buona idea. DAO dovrebbe essere limitato per aggiungere / aggiornare / inserire / selezionare oggetti Entity nel / dal 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 alcune parti dei dati). Ciò è particolarmente applicabile nelle applicazioni che coinvolgono report con logiche pesanti anche dopo il recupero dei dati dal database.

Inoltre, in primavera, la sicurezza viene applicata idealmente al livello di servizio. Non vorresti cambiare in questo modo.

— lokesh
fonte

5

Ehi, grazie mille per aver risposto alla mia domanda; questa è dedizione per il tuo blog! Grazie per il grande esempio, continua a scrivere.

— Jeff,

Questo mi ha infastidito per un po 'di tempo e penso che l'esperienza aiuti di più in queste situazioni. Grazie.

— Utku Özdemir,

Sono d'accordo con la separazione dei livelli di servizio e dao e il livello di servizio contenente la tua logica aziendale e chiamerei solo i metodi Dao. Che dire di quando uno dei miei metodi di servizio deve chiamare un altro metodo di servizio. Dovrei avere un'altra astrazione sopra il livello di servizio che chiama più metodi di servizio?

— Peter Delaney,

No. Le classi a livello di servizio possono avere riferimenti reciproci (se necessario) e possono chiamare i metodi richiesti.

— lokesh,

11

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

http://realworldpatterns.com/

Nel mondo Java EE non c'è quasi mai bisogno 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 una sbronza della povera architettura J2EE di 15 anni fa, ma molte persone si sentono ancora obbligate a farlo. Questi layer DAO personalizzati spesso forniscono nient'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 un DAO, ma devi solo scrivere il livello di servizio.

— Dean Schulze
fonte

2

Non sono sicuro che si applichi a Spring: esiste sempre un DAO personalizzato che deve essere creato per il modello. Forse la tua affermazione "non c'è quasi mai bisogno di scrivere il tuo DAO" si applica specificamente ai container / server applicazioni EJB?

— Don Cheadle,

1

È meglio scrivere il proprio (DAO / DAOImpl), anche se verrà mappato solo su EntityManager - Ecco perché in futuro è possibile aggiungere un'altra implementazione DAO senza dover modificare il codice del livello di servizio .

— ahmednabil88,

@YajliMaclo qual è la differenza cosa cambiare?

— Alex78191,

4

Di solito inserisco tutto il codice specifico del database (query) in DAO e la gestione delle transazioni e la logica aziendale nei servizi. Ciò consente ai metodi di servizio di invocare metodi su più DAO e di mantenerli tutti all'interno della stessa transazione. A mio avviso, ciò consente un migliore riutilizzo del codice su dao.

— sbrattla
fonte

2

Ho scoperto che il livello di servizio aggiunge complessità inutili nella maggior parte dei casi. In teoria è evitare di avere una logica di business nel livello dao ma alla fine questo porta solo a confusione, anche alcune persone hanno disuso di rimuovere completamente il livello dao poiché ritengono che non aggiunga valore. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

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

— Gesù
fonte

3

Ho letto più volte il post sul blog di Ayende e non riesco proprio a scuotere la sensazione che il suo design (con cui avrei concordato ad un certo punto), pur fedele allo spirito di YAGNI, sarebbe quasi inevitabilmente costato più tempo di sviluppo anche nel a medio termine di quanto significherebbe in primo luogo impostare l'astrazione degli strati. Mi chiedo se abbia cambiato opinione sull'accoppiamento stretto tra l'intera applicazione e NHibernate ora che è ancora più comune per una singola applicazione interrogare più origini dati SQL, NoSQL e API.

— Mr Cochese,

@LennyGodber sì, so che hai la sensazione che l'IMO sia meglio avere il livello DAO / repository perché poiché ha più vantaggi che svantaggi perché, come dicevi, è molto comune avere più origini dati

— Gesù,

-1

IMHO il livello di servizio può essere considerato come un livello tra il livello controller e 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.

— compserve23
fonte