JSF Livello di Servizio

Io non sono sicuro se il mio approccio con l’MVC ambiente in JSF è il modo migliore per andare. Dal momento che sto cercando di ottenere il più fuori di JSF vorrei sapere come il mio Livello di Servizio (o di un Modello, parlando in MVC termini) devono essere concepiti.

So che il View-Controller rapporto dovrebbe essere di 1 a 1 (eccezioni da escludere).
Ora, in che modo posso realizzare il mio Livello di Servizio? Devo utilizzare un grande servizio (non credo)? Se non basandosi su ciò che devo dividere i miei servizi?

Nota, il mio Servizio sarà chiamato dai Fagioli (Controller MVC termini) e il Servizio stesso sarà chiamata DAO tramite JPA quando necessario.

Grazie in anticipo

InformationsquelleAutor Menno | 2012-10-22

 

2 Replies
  1. 39

    Il livello di servizio (business model) devono essere progettati in giro per le principali entità (il modello di dati). E. g. UserService per User, ProductService per Product, OrderService per Order, etc. Che non si dovrebbe assolutamente avere una vasta classe di servizio o giù di lì. Che estrema accoppiamento stretto.

    Come per il livello di servizio API di se stesso, Java EE 6 offre EJB 3.1 come livello di servizio API. Nel buio J2EE età, tanto tempo fa, quando EJB 2.0 è stato terribile per sviluppare con, Primavera, era stata più spesso utilizzato come livello di servizio API. Alcuni ancora in uso oggi, ma dal momento che Java EE 6 ha incorporato tutte le belle lezioni apprese dalla Primavera, è diventato superfluo. Nota che EJB (e APP) non è disponibile in barebone servletcontainers come Tomcat. Dovresti installare per esempio OpenEJB su di essa (o solo l’aggiornamento a TomEE).

    Indipendentemente dal livello di servizio API di scelta, la cosa migliore sarebbe di mantenere il vostro JSF backing bean (azione)metodi listener come slick come possibile da che svolgono attività di lavoro interamente nel livello di servizio. Si noti che il livello di servizio dovrebbe di per sé non hanno JSF dipendenze. Quindi, qualsiasi (in)diretta importazioni di javax.faces.* nel livello di servizio codice indica cattivo design. Si consiglia di mantenere il particolare righe di codice nel backing bean (di solito è il codice che aggiunge un facce messaggio a seconda del servizio di chiamata di risultato). In questo modo il livello di servizio è riutilizzabile per altri front-end, come JAX-RS o anche semplice servlet.

    Si dovrebbe capire che il vantaggio principale di il livello di servizio in un’applicazione Java EE è la disponibilità di contenitore di transazioni gestite. Un metodo di servizio di chiamata su un @Stateless EJB conta in modo efficace come un unico DB transazione. Quindi, se si verifica un’eccezione durante una qualsiasi DAO operazioni utilizzando @PersistenceContext EntityManager cui viene richiamato il metodo del servizio di chiamata, quindi un completo rollback verrà attivato. In questo modo si finisce con un panno pulito DB di stato invece di uno sporco DB di stato, perché, per esempio il primo DB manipolazione query è riuscito, ma il secondo non.

    Vedere anche:

    • Allora.. Il Servizio sarebbe un Rapporto di 1: 1 se lo si confronta con il DAO (e di che Entità)? Il resto della tua spiegazione è chiaro al 100%, lo scopo del mio servizio è già ok (così la logica di business, non JPA logica, non JSF logica). Ho bisogno di guardare in il diritto ambiti et cetera po ‘ di più. Ancora una volta, grazie 🙂
    • Non esattamente 1:1. È possibile avere più di Tao iniettato in una singola classe di servizio. Dipende dal fatto che la stessa entità che ha ogni bambino entità.
    • è comune avere una sospensione di classe dichiarata come JSF bean? Per esempio, ho un punto di vista della Società (che ha la proprietà di nome, indirizzo, contatti, ecc). Sto avendo un problema, perché oltre a tutte le proprietà dell’Azienda, ho un Elenco<Azienda>. È mi dà un errore, perché dal momento che si tratta di una sospensione di classe, si sta cercando di trovare una colonna di tipo List<Azienda>, che non esiste. Io sono in grado di risolvere il problema, rendendo transitoria. Ma questa è una buona pratica?
    • Controllare il “Vedi anche” link per esempi concreti di un corretto utilizzo di classi di entità e classi di servizio in backing bean classi.
    • Si dovrebbe capire che il vantaggio principale di il livello di servizio in un’applicazione Java EE è la disponibilità di contenitore di transazioni gestite. mi piace questo
    • E che dire di questa soluzione : Ejb per alcune abstract facciate (a Livello di Servizi) e CDI fagioli per i controller, dietro la facciata (Livello aziendale) Entità per il modello (Data Access Layer)?

  2. 3

    Il rapporto 1:1 tra i servizi e le entità del modello forse non è male se si hanno poche entità dell’app. Ma se è un grande app, ci sarebbe troppo secco.

    Il numero di servizi dipende i casi d’uso dell’applicazione che si sta progettando. Una volta individuate nella fase di analisi, è necessario un gruppo di loro in diversi gruppi in base alla loro funzionalità. Ogni gruppo di casi di utilizzo del Servizio, e in ogni caso di utilizzo sarà un metodo in quel servizio. Ogni Servizio può gestire diverse entità del modello (e si deve iniettare in esso la Tao deve eseguire la sua funzionalità). Di solito i casi di utilizzo di un Servizio gestire le entità del modello di inter-realationated nel diagramma delle classi del modello. I Servizi potrebbero seguire le buone pratiche di “massima coesione /min coppia”.

    Il rapporto tra Tao e le entità del modello è 1:1. Ogni DAO eseguire operazioni CRUD e le query di sua entità. Se un metodo ha bisogno di query 2 relationated entità, metterlo nella più adatto DAO a seconda dei concetti di business.

    In JSF livello di presentazione non hanno un rapporto 1:1 tra le pagine ed i controllori, che sarebbe troppo controller. Ho un gruppo in una contrller tutte le pagine necessarie per eseguire i casi di utilizzo di ciascun servizio. Così il rapporto 1:1 tra controllori e servizi, l’iniezione ogni servizio del controller di cui le pagine di eseguire i suoi casi d’uso.

    Naturalmente, questi sono i principi generali. Si può avere alcuni casi particolari in app che si è rotto, ma sono pochi.

    Si potrebbe non avere troppo di servizi e controller, ma non troppo pochi né perché poi sarebbe troppo logico e campi. Si deve acchieve un compromesso.

Lascia un commento