Utilizzo di servizi e DAO nel controller mvc di primavera

Question

Sto creando un'applicazione Web che costituisce principalmente operazioni CRUD di dati dal back-end/database. Ci sono casi in cui devo scrivere una logica di business (sono sicuro che avremo più logiche di business costruite man mano che approfondiremo lo sviluppo). Attualmente per ogni schermata dell'interfaccia utente che sto creando, creo una classe modello, una classe Service, una classe DAO, un controller (è essenzialmente un servlet) e un mucchio di pagine jsp. Nella maggior parte dei casi, la classe di servizio chiama solo i metodi DAO per passare gli oggetti del modello. In sostanza, utilizziamo le classi del modello per mappare i dati dagli schermi dell'interfaccia utente. Quindi il controllore avrà gli oggetti del modello popolati quando viene inviato un modulo. Ho iniziato a utilizzare le classi di servizio per mantenere un livello di separazione dal livello Web al livello DAO. Ma a volte penso che la classe di servizio stia semplicemente aggiungendo un livello non necessario di chiamate API, penserei che potrei semplicemente iniettare il DAO nel controller e completare l'attività più velocemente. Voglio utilizzare la classe di servizio solo quando è necessario eseguire una business logic aggiuntiva. Se devi progettare un'applicazione, quali fattori consideri utilizzando controller-> DAO vs controller-> Servizio-> flusso di controllo DAO?

Answer 1

I DAO sono più granulari e si occupano di un'entità specifica. I servizi forniscono funzionalità a livello di macro e possono finire per utilizzare più di un DAO. In genere, i servizi vengono utilizzati per definire i limiti delle transazioni per ottenere l'atomicità. In altre parole, se si termina l'aggiornamento di più tabelle utilizzando più DAO, la definizione del limite di transazione al servizio consentirà di eseguire il commit o il rollback di tutte le modifiche apportate al DB.

Nella progettazione, poiché si esegue principalmente CRUD per varie entità, potrebbe sembrare che i servizi non aggiungano molto valore. Tuttavia, considera il front-end basato sul Web come un modo per aggiornare i dati. L'utilizzo dei servizi ti consentirà di esporre le stesse funzionalità di un servizio web in seguito ad altre forme di client come integratori di terze parti, ecc.

Quindi, in sintesi, il tuo progetto sembra essere in linea con le pratiche convenzionali. Se ritieni di poter combinare più servizi in uno basato su un tema comune, in modo da ridurre il sovraccarico di codice, devi procedere e farlo. Alla fine della giornata, l'obiettivo finale è quello di creare un codice gestibile che nessuno ha paura di cambiare quando si presenta la necessità.

Answer 2

avrei riferisco la mia risposta here

Il lungo e breve di esso è il vantaggio di utilizzare un livello di servizio è che ti dà spazio per muoversi in futuro, se si vuole fare qualcosa con Primavera di sicurezza e ruoli ecc. Ti permette di gestire le transazioni in modo più atomico e Spring stessa ha annotazioni davvero belle per questo.

Answer 3

Utilizzare una classe di servizio quando si ha a che fare con più di uno aggregate root.

Inject repositories (ovvero un dao che restituisce una raccolta) o dao direttamente nel controller, non è necessario un layer/classe extra per eseguire un get di base.

Utilizzare solo classi di servizio dove necessario, altrimenti si dispone del doppio del codice richiesto.

È possibile creare un repository generico, e annoato con @Transactional(propagation = Propagation.REQUIRED) che applica una transazione, ma non ne creerà uno nuovo se già presente. Quindi, se in seguito utilizzi più repository in un metodo di classe di servizio, avrai solo una transazione.

Answer 4

In Pro-Spring-3 book hanno accennato sotto la linea, per il controller con JPA2

Once the EntityManagerFactory had been properly configured, injecting it into your service layer 
classes is very simple. 

e stanno usando la stessa classe di servizio e repository come in seguito:

package com.apress.prospring3.ch10.service.jpa; 
// Import statements omitted 
@Service("jpaContactService") 
@Repository 
@Transactional 
public class ContactServiceImpl implements ContactService { 
private Log log = LogFactory.getLog(ContactServiceImpl.class); 
@PersistenceContext 
private EntityManager em; 
// Other code omitted 
} 

ma nel caso in cui si utilizzi il CRUDRepository o il JPARepository di dati primari, il DAO sarà Interfaccia e sarà necessario creare un livello di servizio per gestire il codice