Se non esiste una logica aziendale da eseguire, non c'è motivo di imporre un livello aziendale. L'architettura a 3 livelli non è un protocollo arcano, solo una best practice che è stata formata assumendo l'elaborazione aziendale.
In un'applicazione corrente si accede spesso ai DAO direttamente dai controller JSF quando non è coinvolto alcun processo aziendale. L'idea è stata data da un java champion che ha sottolineato l'idea che la semplicità è fondamentale.
Se si è preoccupati per le modifiche future che potrebbero richiedere l'aggiunta di business logic. Penso al problema in questo modo: la logica aziendale aggiuntiva verrebbe comunque aggiunta al livello aziendale, incluso l'accesso ai dati, quindi non c'è alcuna differenza qui.
Il codice CRUD è in gran parte molto semplice. Quindi il cambiamento nel servizio equivarrebbe a reindirizzare una singola chiamata o un paio di chiamate dal DAO a un EJB - un semplice refactoring. Il codice CRUD stesso rimarrebbe, ma verrà inserito nel bean, un altro semplice refactoring.
Questo non è perfetto, ma IMO meglio l'alternativa: avere uno strato di riferimento indiretto vuoto. Ciò aggiunge complessità che non ha alcuno scopo. L'oggetto business non farebbe altro che inoltrare le chiamate al DAO.
Ci sono due code smells che penso si applichino in questo caso: complessità artificiosa e feature envy.
Non sto dicendo che DA nel livello aziendale è in qualche modo un odore di codice. Quello che voglio dire è che avere un oggetto business che fa nient'altro ma che il DAO è proxy è un odore. Lo stesso vale per la complessità: una struttura dati aggiunta/un livello architettonico che non serve a nessuno scopo: sembra che ci sia già un DAL nella tua applicazione.
Un altro aspetto da tenere in considerazione sarebbe: quanto è sorprendente per uno sviluppatore vedere un servizio che utilizza direttamente un DAO? Avere 5 servizi in cui 2 di essi accedono direttamente a DAO è diverso dall'avere 100 servizi in cui solo un servizio accede direttamente ai DAO.
Nel primo caso la semplicità del codice supererebbe la complessità concettuale aggiunta (2 concetti per una singola cosa), nel secondo caso preferirei rimanere con il livello aziendale: la sorpresa (detta anche effetto WTF;) di farlo diversamente solo una volta sarebbe troppo grande.
Come al solito, cristallino! Anche se la domanda è auto-contraddittoria in natura ("come posso saltare sempre il livello intermedio in un'applicazione che si basa su di esso"). – skuntsel
@skuntsel - grazie :) Sì, se i DAO sono considerati parte del livello aziendale, allora sei fissato con i 3 livelli - per me i DAO fanno parte del DAL, quindi sto perdendo uno strato con un verbo economico trucco;) – kostja
E se in un secondo momento dovessi aggiungere un po 'di business prima di fare operazioni CRUD? se aggiungi il codice aziendale nel livello di servizio è sbagliato perché i servizi non dovrebbero avere codici aziendali, quindi devi aggiungere business in Business Layer, cambiare il servizio per ottenere la sua attività e fare il suo lavoro quindi devi cambiare 2 luoghi diversi per aggiungere attività commerciale. che è un problema, credo! –