Quale modello di progettazione è meglio lavorare con Controllers/Services/DAO

Question

Durante la mia carriera ho visto pochi disegni diversi, come lavorare con DAO, Service, Controller layer. Voglio chiedere due, che sono simili ma hanno poche differenze. Il primo disegno crea una barriera visibile tra i livelli. I controllori utilizzano sempre servizi e solo servizi. I servizi possono utilizzare altri servizi o DAO. I controllori non possono utilizzare direttamente alcun DAO. Questo design è chiaro, ma ha grandi svantaggi per me: dobbiamo sempre creare un metodo in servizio per ogni metodo in DAO. Ma in molti casi i metodi di servizio invocano solo i metodi DAO e qualsiasi altra cosa.

Per esempio: Abbiamo UserDao

class UserDao { 
    public List<User> findByName(String name) { ... } 
    public List<User> findByLastName(String name) { ... } 
    public List<User> findOlderThan(int age) { ... } 

    ...... 
} 

Tutti i metodi di cui sopra sono utilizzati dai controllori. Cosa dovremmo fare nel nostro caso? Creare metodi simili in UserService:

class UserService { 
    public List<User> findByName(String name) { return userDao.findByName(name); } 
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); } 
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); } 

    ...... 
} 

Per me questo è ulteriore strato di inutile per i metodi di sola lettura.

In secondo design non abbiamo un problema con questo perché possiamo usare DAO direttamente in Controller. In questa progettazione abbiamo una regola: se vogliamo recuperare un dato da "archivio dati" possiamo usare DAO in qualsiasi livello, se vogliamo apportare alcune modifiche in "archivio dati" dobbiamo usare metodi di servizio.

Cosa ne pensi, ragazzi, di questi progetti? Che è migliore? Quale dovrei usare nei miei progetti e quale dovrebbe essere dimenticato? Potresti condividere con me la tua esperienza in questa sfera?

Answer 1

I servizi, in modelli di progettazione ispirati a MVC e MVC sono la "parte superiore" del livello del modello. È il modo in cui il livello di presentazione interagisce con la logica di business del dominio (inoltre, la parte "lettura" dovrebbe essere eseguita da istanze di visualizzazione, in realtà).

In tale struttura i servizi fungono da barriera, che isola lo strato di presentazione e offre maggiore libertà nel modificare la struttura interna del modello in un secondo momento.

Un'altra cosa da tenere a mente è che ci sono più strutture quindi solo con i servizi che interagiscono con gli DAO s. Prima di tutto ci sono domain objects (oggetti business, oggetti modello) che incapsulano le diverse regole di business che si riferiscono a una particolare entità. Quindi puoi anche avere data mappers, che astraggono la logica di archiviazione invece dei DAO. O DAO che traducono le informazioni tra i mapper e gli oggetti del dominio. Nell'applicazione su più larga scala sarebbe anche unit(s) of work. In scala più piccola, con alcune istanze di active record andrebbe bene.

Si potrebbe dire che il livello del modello contiene tre gruppi principali di struttura in cui l'attrezzo separa gli aspetti del modello: dominio, memoria e logica dell'applicazione.

La logica dell'applicazione è l'interazione tra gli oggetti del dominio delle strutture di memoria. Questo è ciò che i servizi sono responsabili.

Se si espone DAO, il livello del modello inizia a filtrare nella presentazione. Il controllore non dovrebbe avere idea di quali strutture sono usate e quando sono persistenti.