Perché non dovrei usare un fagiolo JSF SessionScoped per la logica?

Question

sto sviluppando una web app Java EE usando JSF con un processo di stile carrello della spesa, quindi voglio raccogliere l'input dell'utente per un certo numero di pagine e poi fare qualcosa con esso.

Stavo pensando di utilizzare un session bean stateful EJB 3 per questo, ma la mia porta di ricerca farmi credere che uno SFSB non è legato alla sessione http di un cliente, quindi avrei dovuto tenere manualmente traccia di esso tramite un HttpSession, alcune domande collaterali qui. . .

1) Perché si chiama un session bean, per quanto posso vedere non ha nulla a che fare con una sessione, ho potuto ottenere lo stesso per la memorizzazione di un POJO in una sessione.

2) Qual è il punto di essere in grado di iniettare, se tutto quello che sarò l'iniezione di' è una nuova istanza di questo SFSB allora potrei anche usare un POJO?

Ma torniamo al problema principale che vedo scritto dappertutto che JSF è una tecnologia di presentazione, quindi non dovrebbe essere usato per la logica, ma sembra la soluzione ideale per la raccolta di input dell'utente.

posso impostare una sessione di JSF bean ambito come una proprietà gestita di tutti i miei fagioli richiesta che significa che è iniettato in loro, ma a differenza di una SFSB JSF sessione gestita con scope di fagioli è legata alla sessione HTTP e quindi la stessa istanza è sempre iniettata fino a quando la sessione HTTP non è stata invalidata.

Così ho più livelli

1 ° livello) JSF richiesta gestito ambito fagioli che si occupano di presentazione, 1 per pagina.
2 ° livello) Un JSF gestito con scope di sessione di fagioli che ha valori impostati in essa i fagioli richiesta.
3 ° livello) Un stateless EJB sessione che esegue la logica sui dati della sessione JSF bean con scope.

Perché è così cattivo?

opzione alternativa è quella di utilizzare uno SFSB ma poi devo iniettare nel mio fagioli richiesta iniziale e poi memorizzarlo nella sessione HTTP e afferrarlo di nuovo in ogni successiva richiesta di fagioli -. Sembra proprio disordinato

O potrei semplicemente memorizzare tutto nella sessione, ma questo non è l'ideale in quanto prevede l'utilizzo di tasti letterali e casting. ecc .. ecc, che è soggetto a errori. . . e disordinato!

Ogni pensiero apprezzato Mi sento come sto combattendo questa tecnologia piuttosto che lavorare con esso.

Grazie

Answer 1

  

Perché si chiama un session bean, per quanto posso vedere non ha nulla a che fare con una sessione, ho potuto ottenere lo stesso per la memorizzazione di un POJO in una sessione.

Dal vecchio J2EE 1.3 Esercitazione :

  

Che è un session bean?

     

Una session bean rappresenta un singolo   client all'interno del server J2EE. Per   accedere a un'applicazione che viene distribuita   sul server, il client richiama il   metodi sessione bean. La sessione   esegue fagiolo lavorano per il suo cliente,   schermatura del client da complessità   eseguendo le attività di business all'interno del   server.

     

Come suggerisce il nome, un session bean   è simile a una sessione interattiva.   Una session bean non è condivisa - può   avere un solo cliente, allo stesso modo   che una sessione interattiva può avere   un solo utente. Come un interattivo   sessione, un session bean non è   persistente. (Cioè, i suoi dati non è   salvato in un database.) Quando il client   termina, le sue appare session bean   per terminare e non è più   associato al client.

Quindi, ha a che fare con una "sessione". Ma sessione non significa necessariamente "sessione HTTP"

  

Qual è il punto di essere in grado di iniettare, se tutto quello che sarò l'iniezione di' è una nuova istanza di questo SFSB allora potrei anche usare un POJO?

Beh, prima di tutto, non fare iniettare uno SFSB nella componente senza stato (iniezione in un altro SFSB sarebbe ok), devi fare una ricerca. In secondo luogo, scegliendo tra sessione HTTP e SFSB realtà dipende dalla vostra applicazione e le vostre esigenze. Da un punto di vista puramente teorico, la sessione HTTP deve essere utilizzato per la presentazione stato logico (ad esempio dove siete nel vostro modulo multi pagina) mentre lo SFSB dovrebbe essere utilizzato per lo stato della logica di business. Questo è ben spiegato nella "vecchia" HttpSession V.S. Bean di sessione stateful thread su TSS che ha anche un esempio bello dove SFSB avrebbe senso:

  

Si consiglia di utilizzare una sessione stateful   fagiolo per monitorare lo stato di un   particolare operazione. cioè qualcuno   l'acquisto di un biglietto ferroviario.

     

Il web sessione tiene traccia dello stato di   in cui l'utente si trova nella pagina html   flusso. Tuttavia, se l'utente poi guadagnato   accesso al sistema attraverso un   canale differente per esempio un telefono WAP, o   attraverso un call center si farebbe ancora   vuole conoscere lo stato del biglietto   acquisto di transazione.

Ma SFSB non sono semplici e se non si hanno esigenze che giustificano il loro uso, il mio consiglio pratico sarebbe quello di attaccare con la sessione HTTP (soprattutto se tutto questo è nuovo a voi). Solo nel caso, consultare:

• Stateless e Stateful Enterprise Java Beans
• Stateful EJB in applicazioni web?

  

Ma torniamo al problema principale che vedo scritto dappertutto che JSF è una tecnologia di presentazione, quindi non dovrebbe essere usato per la logica, ma sembra la soluzione ideale per la raccolta di input dell'utente.

Non è la logica di business, che è la logica di presentazione.

  

Così ho più livelli (...)

No. Avete probabilmente un livello client, un livello di presentazione, un business di livello, un livello dati. Quello che stai descrivendo sembra più strati (non sono nemmeno sicuro). Vedi:

• Qualcuno può spiegare queste parole: Presentazione Tier, Affari Tier, Integrazione Tier in Java EE con l'esempio
?
• Spring, Hibernate, Java EE nell'architettura 3 Tier

  

Perché è così cattivo?

Non lo so, non so che cosa stai parlando :) Ma si dovrebbe probabilmente solo raccogliere le informazioni a più modulo pagina in un fagiolo SessionScoped e chiamare un Stateless Session Bean (SLSB) alla fine del processo.

Answer 2

  

1) Perché si chiama un session bean, per quanto posso vedere non ha nulla a che fare con una sessione, ho potuto ottenere lo stesso per la memorizzazione di un POJO in una sessione.

Correzione: una sessione EJB non ha nulla a che fare con una sessione HTTP. In EJB, grosso modo, ha detto, il cliente è il contenitore di servlet e il server è il contenitore EJB (sia in esecuzione in un web server / applicazioni). In HTTP, il cliente è il web browser e il server è il server web / applicazioni.

Ha più senso ora?

  

2) Qual è il punto di essere in grado di iniettare, se tutto quello che sarò l'iniezione di' è una nuova istanza di questo SFSB allora potrei anche usare un POJO?

Usa EJB per le attività di business transazionali. Utilizzare una sessione ambito bean gestito a dati specifici della sessione negozio HTTP. Nessuno di entrambi sono POJO di proposito. Basta Javabeans.

  

Perché non dovrei usare un fagiolo JSF SessionScoped per la logica?

Se non si è tenuto a beneficio di attività di business transazionali e l'EJB astrazione fornisce intorno ad esso, poi basta farlo in un fagiolo semplice JSF gestito non è davvero una cattiva alternativa. Questo è anche l'approccio normale nelle applicazioni JSF di base. Le azioni sono però di solito da prendere posto in una richiesta scope bean gestito in cui scope sessione uno è stato iniettato come @ManagedProperty.

Ma dal momento che si sta già utilizzando EJB, mi chiedo se non ci fosse un motivo specifico per l'utilizzo di EJB. Se questo è il requisito di business da sopravvento, allora avevo appena bastone ad esso. Almeno, la sessione-confusione dovrebbe essere chiarito.

Answer 3

Nel caso in cui non sei a conoscenza di questo, e come un piccolo contributo per le risposte che avete, si potrebbe effettivamente anotate uno SFSB con @SessionScoped, e CDI gestirà il ciclo di vita del bean ... Questo sarebbe legare un EJB alla sessione HTTP che gestisce CDI. Solo ti permette di sapere, perché nella sua domanda si dice:

but my research leads me to believe that a SFSB is not tied to a client's http session, so I would have to manually keep track of it via an httpSession, some side questions here . . .

Inoltre, si potrebbe fare quello che suggeriscono, ma dipende dalle vostre esigenze, fino a quando i fagioli CDI ottenere il supporto delle transazioni dichiarativa o esteso la persistenza contesti ecc, vi ritroverete a scrivere un sacco di codice boilerplate che renderebbe il bean meno pulito . Naturalmente è anche possibile utilizzare framework come Seam (ora di trasferirsi a DeltaSpike ) per migliorare alcune capacità delle vostre fagioli attraverso le loro estensioni.

Quindi direi di sì, a prima vista si può sentire che non è necessario usare un EJB stateful, ma alcuni casi d'uso può essere migliore di risolvere attraverso di loro. Se un utente aggiunge un prodotto al suo carro, e un altro utente aggiunge questo stesso prodotto in seguito, ma non v'è una sola unità in azione, chi ne è affetto? colui che fa cassa più veloce? o quello che ha aggiunto per primo? Che cosa succede se si desidera accedere al gestore di entità a persistere un kart nel caso in cui l'utente decida di casualmente vicino il suo browser o cosa succede se si dispone di transazioni che depongono le uova più pagine e si desidera che ogni passo per essere sincronizzati con il db? (Per mantenere una transazione aperta per così tanto tempo non è consigliabile, ma forse ci potrebbe essere uno scenario in cui questo è necessario?) Si potrebbe usare SLSB ma a volte è meglio e più pulito di utilizzare una SFSB ..