Le migliori pratiche DAO (oggetto di accesso ai dati) - esempi che vedo utilizzare un DAO e un oggetto Servizi entrambi, qual è la migliore pratica qui?

Question

Sto creando un oggetto di accesso ai dati per recuperare informazioni da Google App Engine per un'app Web costruita nel framework Spring (prima volta per tutte).

Vedo un certo numero di esempi che utilizzano un controller/webapp -> Servizio -> DAO -> JDO/modello di motore dell'app Google.

In questo modello, il livello DAO è l'unico che conosce JDO, quindi questo livello è l'unico da sostituire se l'archivio dati è stato modificato. Il livello Servizi chiama il livello DAO e formatta/manipola i dati necessari.

La mia domanda è perché il livello di servizio aggiuntivo? Almeno all'inizio non sembra che il livello di servizio aggiunga molto all'equazione. Naturalmente penserei di scrivere solo un livello DAO per incapsulare le richieste JDO e manipolare e restituire i dati.

Qualcuno può mostrarmi il razionale per un livello di servizio separato, questo diventerà ovvio in quanto il progetto diventa più grande e più complesso?

Answer 1

In genere, i DAO vengono inseriti in un livello di servizio perché con l'app che diventa più complicata, nel servizio verranno eseguite operazioni utili e non banali. Ad esempio, è possibile coordinare operazioni di dati complicate con più di 1 DAO. I livelli di servizio forniscono anche limiti API che delimitano preoccupazioni trasversali, come la gestione delle transazioni, controlli di autorizzazione, registrazione delle prestazioni, ecc.

Un altro motivo per cui è utile astrarre la funzionalità nei servizi è che promuove componenti riutilizzabili e manutenibili. Quando inizi, potresti essere interessato a presentare solo alcuni html. Scrivi un servizio che carica alcuni dati e gestisce la parte html nel livello sopra il livello di servizio (livello di presentazione). Ora vuoi mettere in piedi un webservice RESTful. Il tuo livello di servizio può essere riutilizzato per caricare i dati; tutto ciò di cui ti devi preoccupare è il json o xml che i tuoi endpoint webservice restituiscono (e ovviamente la semantica REST).

Quindi, per casi semplici il livello Servizio potrebbe aggiungere poco, ma man mano che la tua app si espande diventano utili e addirittura essenziali per mantenere pulito il codice.

Answer 2

Sì, inizialmente sembra che il livello di servizio non aggiunga molto all'equazione. Ma pensaci in questo modo.

Service Layer = un livello tra la presentazione e il livello aziendale.

È necessario essere consapevoli che è sempre bene avere separazione delle preoccupazioni tra gli strati. Il tuo livello di servizio può essere associato a diversi domini aziendali, livelli di presentazione, senza essere disturbato da come viene utilizzato il tuo livello DOA.

Si può pensare a questo come al confine tra altri due livelli, in questo caso tra la presentazione ei livelli aziendali. Il codice nel livello di presentazione implementa in genere casi d'uso. Un tipico caso d'uso è una sequenza di azioni eseguite dall'utente che determinano interazioni tra uno o più oggetti di business, flussi di lavoro e servizi. Il livello di servizio consente di astrarre queste interazioni più piccole con un'API intermedia, esposta attraverso servizi più grossolanamente granulari. Il livello di presentazione effettua una chiamata a un servizio nel livello. Il metodo del livello di servizio invocato coordinerà gli oggetti e i flussi di lavoro nel livello aziendale per implementare il comportamento richiesto.

problemi di sicurezza

1. faccio a creare un livello di sicurezza intorno alle pile di servizio. Questo mi aiuterà a identificare l'autenticità dell'utente e ad accedere al servizio dato.
2. Ho anche un livello di transazione definito attorno al livello di servizio, dice al motore del database di salvare le modifiche apportate nel livello di servizio, una volta che viene restituito dopo le esecuzioni riuscite.

Queste cose devono anche essere preoccupanti se si definiscono i livelli dell'applicazione.