Perché utilizzare il livello di servizio?

Question

Ho guardato l'esempio a http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639

Sto cercando di capire il motivo per cui è necessario il livello di servizio, in primo luogo nell'esempio egli fornisce. Se hai preso fuori, poi nel vostro cliente, si può solo fare:

UserDao userDao = new UserDaoImpl(); 
Iterator users = userDao.getUsers(); 
while (…) { 
… 
} 

Sembra che il livello di servizio è semplicemente un wrapper per il DAO. Qualcuno può darmi un caso in cui le cose potrebbero diventare disordinate se il livello di servizio è stato rimosso? Solo non vedo il punto di avere il livello di servizio per cominciare.

Answer 1

Avere il livello di servizio sia un involucro intorno al DAO è un anti-modello comune. Nell'esempio che gli dai non è certamente molto utile. Utilizzando un livello di servizio significa che ottenere diversi vantaggi:

• si arriva a fare una chiara distinzione tra l'attività di tipo web meglio farlo nel controller e la logica business generico che non è web-related. È possibile testare la business logic relativa ai servizi separatamente dalla logica del controller.

• consente di specificare il comportamento della transazione, quindi se si dispone di chiamate a più oggetti di accesso ai dati è possibile specificare che si verificano all'interno della stessa transazione. Nel tuo esempio c'è una chiamata iniziale a un dao seguita da un ciclo, che potrebbe presumibilmente contenere più chiamate dao. Mantenere quelle chiamate all'interno di una transazione significa che il database fa meno lavoro (non è necessario creare una nuova transazione per ogni chiamata a un Dao) ma, soprattutto, significa che i dati recuperati saranno più coerenti.

• è possibile nidificare i servizi in modo che se uno ha un comportamento transazionale diverso (richiede una propria transazione) è possibile applicarlo.

• è possibile utilizzare l'intercettore PostCommit per inviare notifiche come l'invio di e-mail, in modo da non far arrendere il controller.

In genere devo servizi che comprendono i casi d'uso per un solo tipo di utente, ogni metodo del servizio è una singola azione (lavoro da fare in un singolo ciclo di richiesta-risposta), che l'utente avrebbe esibirà e, a differenza del tuo esempio, di solito c'è più di una semplice chiamata a un oggetto di accesso ai dati.

Answer 2

Date un'occhiata al seguente articolo:

http://www.martinfowler.com/bliki/AnemicDomainModel.html

Tutto dipende da dove si desidera inserire la logica - nei vostri servizi o gli oggetti del dominio.

Il servizio approccio strato è appropriata se si dispone di un'architettura complessa e richiedono diverse interfacce per il tuo DAO e di dati. È anche utile fornire dei metodi granulari per i corsi da chiamare, che chiamano più DAO per ottenere i dati.

Tuttavia, nella maggior parte dei casi ciò che si desidera è un'architettura semplice, quindi ignorare il livello di servizio e osservare un approccio basato sul modello di dominio. Domain Driven Design by Eric Evans e l'articolo InfoQ qui espandere su questo:

http://www.infoq.com/articles/ddd-in-practice

Answer 3

Utilizzando livello di servizio è un modello di progettazione ben accettata nella comunità Java.Sì, è possibile utilizzare immediatamente l'implementazione dao, ma se si desidera applicare alcune regole aziendali.

Dire, si desidera eseguire alcuni controlli prima di consentire a un utente di accedere al sistema. Dove metteresti quelle logiche? Inoltre, il livello di servizio è il posto per la demarcazione delle transazioni.

In genere è consigliabile mantenere il livello dao pulito e asciutto. Ti suggerisco di leggere l'articolo “Don’t repeat the DAO”. Se segui i principi in questo articolo, non dovrai scrivere alcuna implementazione per i tuoi daos.

Inoltre, gentilmente notare che la portata di tale post sul blog è stato quello di aiutare i principianti in primavera. La primavera è così potente, che si può piegare in base alle proprie esigenze con i concetti potenti come AOP ecc

saluti, James