Perché utilizzare bean di sessione stateful?

Question

Sto imparando EJB3 e sono curioso di sapere quando è comodo usare SFSB? Non riesco a trovare alcun buon esempio quando SFSB risolve facilmente un problema complesso.

In realtà vedo che SLSB può essere utilizzato come servizi Web e questo è conveniente. Ma non so quando usare SFSB. Vedo solo problemi con esso, perché dovremmo imparare qualcosa al riguardo, dovremmo scrivere un codice che consiste in annotazioni un po 'meno poi completamente, dovremmo usare la ricerca fastidiosa ... e non otteniamo nulla di buono in cambio.

Ad esempio, non è possibile utilizzare SFSB da SLSB, poiché gli oggetti stateful possono essere utilizzati solo dal contesto di stato. Non possiamo usare DI in servlet, ma dovremmo creare manualmente istanze SFSB usando una ricerca JNDI e poi inserirla nell'oggetto HttpSession. Non può essere un servizio web.

L'unico vantaggio che posso vedere in SFSB è una gestione delle transazioni. Ma penso che sia raro quando abbiamo davvero bisogno di una transazione e non abbiamo bisogno di DB. Posso immaginare che possa essere davvero utile quando archiviamo i nostri dati in un file XML e usiamo la gestione delle transazioni in SFSB per gestire il DB non relazionale.

Sono quasi sicuro di sbagliarmi completamente, quindi forniscimi alcuni esempi di utilizzo SFSB.

Answer 1

Sto imparando ejb3 e sono curioso di sapere quando è comodo utilizzare SFSB? Non riesco a trovare alcun buon esempio quando SFSB risolve facilmente un problema complesso.

Intendi come un carrello? Questa è la risposta ovvia a cui posso pensare.

In realtà vedo che SLSB può essere utilizzato come servizi Web e questo è conveniente.

Si può pensare agli EJB come a un modo per distribuire servizi distribuiti, ma attenzione. Il termine "servizi web" fa sì che la maggior parte della gente pensi ai "servizi web basati su SOAP che utilizzano il protocollo HTTP" e questo non è ciò che si ha in un SFSB.

Ma non so quando utilizzare SFSB. Vedo solo problemi con esso perché dovremmo imparare qualcosa al riguardo, dovremmo scrivere un codice che consiste in annotazioni un po 'meno poi completamente, dovremmo usare la ricerca fastidiosa .. E non otteniamo nulla di buono in cambio.

Questo paragrafo è fonte di confusione, ma penso che tu stia dicendo che non ti piacciono molto gli EJB.

Ad esempio, non è possibile utilizzare SFSB da SLSB perché gli oggetti stateful possono essere utilizzati solo dal contesto di stato.

Giusto, sono complementari. Si utilizza SFSB per i casi di utilizzo che richiedono - attendere - lo stato deve essere mantenuto tra le chiamate.

Non è possibile utilizzare DI in servlet, anziché creare manualmente l'istanza SFSB utilizzando la ricerca e quindi inserirla nell'oggetto HttpSession. Non può essere un servizio web.

Da dove vengono i servlet da qui?

L'unico profitto che posso vedere in SFSB è una gestione delle transazioni. Ma penso che sia raro quando abbiamo davvero bisogno di una transazione e non abbiamo bisogno di DB. Posso supporre che possa essere davvero utile quando archiviamo i nostri dati in xml-file e usiamo la gestione delle transazioni in SFSB per simulare il DB non-relazionale.

Penso che tu sia completamente fuori base qui. I bean di sessione sono quelli che conoscono le unità di lavoro e gestiscono le transazioni. Probabilmente devono lavorare con i bean di entità per mantenere un po 'di quello stato quando viene fatto il caso d'uso, quindi le transazioni non sono così rare come sembra.

Sono quasi sicuro di sbagliarmi completamente, quindi forniscimi alcuni esempi davvero utili dell'utilizzo di SFSB.

Qual è la vostra aspettativa? Che qualcuno pubblicherà SFSB funzionante? Non lo farò, soprattutto perché non sono un grande fan dell'EJB. (Faccio tutto ciò a cui allude e di più con Spring.)

Ma certi che gli SFSB sono a volte utili. Il carrello della spesa è l'esempio ovvio. È necessario un luogo in cui conservare gli articoli nel carrello fino a quando il cliente non decide di acquistare. SFSB è un modo per farlo.

Answer 2

è solo una questione di design scegliere tra un'architettura di stato e un'apolidia.

la maggior parte delle volte il design stateless è preferito poiché è più semplice.

sebbene più semplice da capire all'inizio, la creazione di applicazioni stateless porta a una serie di problemi (un sacco di servizi Web stateless, spring singleton, ecc.), Rendendo l'applicazione meno gestibile a lungo termine.

preferisco progettare applicazioni stateful quando possibile.

Il bean di sessione con stato è un modo per farlo. prototipo di molla o fagiolo con scope web altro.

controllare anche jboss seam framework.