¿Por qué usar beans de sesión con estado?

Question

Estoy aprendiendo EJB3 y tengo curiosidad cuando es conveniente usar SFSB? No puedo encontrar ningún buen ejemplo cuando SFSB realmente resuelve fácilmente algún problema complejo.

Actualmente veo que SLSB se puede usar como servicios web y esto es conveniente. Pero no sé cuándo usar SFSB. Solo veo problemas con eso, porque deberíamos aprender algo al respecto, deberíamos escribir código que consiste en anotaciones un poco menos que completamente, deberíamos usar una búsqueda molesta ... y no recibimos nada bueno a cambio.

Por ejemplo, no podemos usar SFSB desde SLSB, porque los objetos con estado solo se pueden usar desde un contexto con estado. No podemos usar DI en servlets, en su lugar debemos crear instancias SFSB manualmente utilizando una búsqueda JNDI y luego ponerlo en el objeto HttpSession. No puede ser un servicio web.

El único beneficio que puedo ver en SFSB es una gestión de transacciones. Pero creo que es un caso raro cuando realmente necesitamos una transacción y no necesitamos DB. Puedo imaginar que puede ser realmente útil, cuando almacenamos nuestros datos en un archivo XML y usamos la administración de transacciones en SFSB para administrar bases de datos no relacionales.

Estoy casi seguro de que estoy totalmente equivocado, así que dame algunos buenos ejemplos del uso de SFSB.

Answer 1

Estoy aprendiendo ejb3 y estoy curioso cuando es conveniente usar SFSB? No puedo encontrar ningún buen ejemplo cuando SFSB realmente resuelve fácilmente algún problema complejo.

¿Te refieres a un carrito de compras? Esa es la respuesta obvia que se me ocurre.

Actualmente veo que SLSB se puede utilizar como servicios web y esto es conveniente.

Puede pensar en los EJB como una forma de implementar servicios distribuidos, pero tenga cuidado. El término "servicios web" hace que la mayoría de la gente piense en "servicios web basados ​​en SOAP utilizando el protocolo HTTP", y eso no es lo que tiene en un SFSB.

Pero no sé cuándo usar SFSB. Solo veo problemas con él porque deberíamos aprender algo al respecto, deberíamos escribir código que consiste en anotaciones un poco menos que completamente, deberíamos usar una búsqueda molesta ... Y no recibimos nada bueno a cambio.

Este párrafo es confuso, pero creo que estás diciendo que no te gustan mucho los EJB.

Por ejemplo, no podemos usar SFSB de SLSB porque los objetos con estado se pueden usar solo desde un contexto con estado.

Correcto, son complementarios. Utiliza SFSB para casos de uso que requieren, espere, estado para mantener entre llamadas.

No podemos usar DI en servlets, en lugar de ello debemos crear manualmente la instancia de SFSB usando la búsqueda y luego ponerla en el objeto HttpSession. No puede ser un servicio web.

¿De dónde vienen los servlets?

La única ganancia que puedo ver en SFSB es una gestión de transacciones. Pero creo que es un caso raro cuando realmente necesitamos una transacción y no necesitamos DB. Puedo suponer que puede ser realmente útil cuando almacenamos nuestros datos en un archivo xml y usamos la gestión de transacciones en SFSB para simular DB no relacionales.

Creo que estás totalmente fuera de la base aquí. Los beans de sesión son los que saben sobre las unidades de trabajo y las transacciones de gestión. Probablemente tengan que trabajar con beans de entidad para persistir un poco de ese estado cuando se complete el caso de uso, por lo que las transacciones no son tan infrecuentes como parece pensar.

Estoy casi seguro de que estoy totalmente equivocado, así que dame algunos buenos ejemplos del uso de SFSB.

¿Cuál es su expectativa? ¿Que alguien publicará SFSB trabajando? No voy a hacer eso, sobre todo porque no soy un gran fan de EJB. (Hago todo lo que está aludiendo y más con Spring.)

Pero tenga la seguridad de que SFSB a veces son útiles. El carrito de compras es el ejemplo obvio. Necesita un lugar para mantener los artículos en el carro hasta que el cliente decida comprarlos. SFSB es una forma de lograr eso.

Answer 2

es solo una cuestión de diseño elegir entre una arquitectura stateful y una apátrida.

la mayoría de las veces se prefiere el diseño sin estado ya que es más fácil.

Aunque es más fácil de entender al principio, la creación de aplicaciones sin estado conduce a una serie de problemas (muchos servicios web sin estado, singleton de primavera, etc.), haciendo que la aplicación sea menos manejable a largo plazo.

prefiero diseñar aplicaciones con estado cuando sea posible.

stateful session bean es una forma de hacerlo. prototipo de primavera o frijol de ámbito web otro.

consulta también jboss seam framework.