¿Por qué no debería usar un grano de JSF SessionScoped para la lógica?

Question

Estoy desarrollando una aplicación web Java EE utilizando JSF con un proceso de estilo carrito de la compra, por lo que quiero cobrar la entrada del usuario a través de una serie de páginas y luego hacer algo con él.

Yo estaba pensando en usar un bean de sesión con estado EJB 3 para esto, pero mis pistas de investigación que crea que un SFSB no está ligado a la sesión HTTP de un cliente, por lo que tendría que mantener un registro manual de la misma a través de una HttpSession, algunas preguntas secundarios aquí. . .

1) ¿Por qué es llamado un bean de sesión, por lo que yo puedo ver que no tiene nada que ver con una sesión, que podría lograr el mismo mediante el almacenamiento de un POJO en una sesión.

2) ¿Cuál es el punto de ser capaces de inyectar, si todo lo que voy a estar inyectando' es una nueva instancia de este SFSB entonces yo también podría utilizar un POJO?

Así que de vuelta a la cuestión principal que veo escrito en la que JSF es una tecnología de presentación, por lo que no se debe utilizar para la lógica, pero parece que la opción perfecta para recoger la entrada del usuario.

Puedo establecer una sesión de JSF frijol con ámbito como una propiedad administrada de todos mis granos de solicitud que significa que es inyectado en ellos, pero a diferencia de un SFSB el JSF sesión logrado con ámbito de frijol está ligada a la sesión HTTP y así la misma instancia es siempre inyectada, siempre y cuando la sesión HTTP no ha sido invalidada.

Así que tengo múltiples niveles

1er nivel) JSF petición logrado con ámbito granos que tienen que ver con la presentación, 1 por página.
Segundo nivel) Un JSF logró sesión de ámbito de frijol que tiene valores establecidos en ella por los granos de petición.
Nivel 3º) Una sesión sin estado EJB que ejecuta la lógica de los datos de la sesión de JSF con ámbito de frijol.

¿Por qué es tan malo?

opción alternativa es utilizar un SFSB pero luego tengo que inyectarla en mi grano de solicitud inicial y luego almacenarla en la sesión HTTP y agarra de nuevo en cada grano de solicitud posterior -. Sólo parece desordenado

O podría almacenar todo en la sesión, pero esto no es ideal, ya que implica el uso de claves literales y fundición. etc .. etc, que es propenso a errores. . . y desordenado!

Cualquier idea apreció me siento como si estuviera luchando contra esta tecnología en lugar de trabajar con él.

Gracias

Answer 1

  

Por qué se llama un bean de sesión, por lo que yo puedo ver que no tiene nada que ver con una sesión, que podría lograr el mismo mediante el almacenamiento de un POJO en una sesión.

A partir de la edad J2EE 1.3 tutorial :

  

¿Qué es un bean de sesión?

     

Un bean de sesión representa una sola   cliente dentro del servidor J2EE. A   acceder a una aplicación que se implementa   en el servidor, el cliente invoca el   métodos sesión de Bean. La sesión   realiza frijol trabajan para su cliente,   protección del cliente de la complejidad   mediante la ejecución de las tareas de negocio dentro de la   servidor.

     

Como su nombre indica, un bean de sesión   es similar a una sesión interactiva.   Un bean de sesión no es compartida - fuere   tener un solo cliente, de la misma manera   que una sesión interactiva puede tener   un solo usuario. Como una forma interactiva   sesión, un bean de sesión no es   persistente. (Es decir, sus datos no es   guardada en una base de datos.) Cuando el cliente   termina, sus aparece bean de sesión   dar por terminado y ya no es   asociado con el cliente.

Así que tiene que ver con una "sesión". Sin embargo, la sesión no necesariamente significa "sesión HTTP"

  

¿Cuál es el punto de ser capaces de inyectar, si todo lo que voy a estar inyectando' es una nueva instancia de este SFSB entonces yo también podría utilizar un POJO?

Bueno, en primer lugar, no hacer inyectar un SFSB en el componente sin estado (inyección en otro SFSB estaría bien), que tiene que hacer una búsqueda. En segundo lugar, elegir entre la sesión HTTP y SFSB realmente depende de su aplicación y sus necesidades. Desde un punto de vista teórico puro de la sesión HTTP se debe utilizar para el estado de la lógica de presentación (por ejemplo, dónde se encuentra en su formulario de varias páginas), mientras que el SFSB se debe utilizar para el estado de la lógica de negocio. Esto está muy bien explicado en la "vieja" HttpSession V.S. beans de sesión con estado hilo sobre TSS que también tiene un buen ejemplo donde SFSB tendría sentido:

  

Es posible que desee utilizar una sesión con estado   bean para rastrear el estado de una   en particular transacción. es decir a alguien   la compra de un billete de tren.

     

La sesión de Web realiza un seguimiento del estado de   donde el usuario se encuentra en la página HTML   fluir. Sin embargo, si el usuario entonces ganó   el acceso al sistema a través de una   diferente canal por ejemplo un teléfono WAP, o   a través de un centro de llamadas que lo haría todavía   querer saber el estado del billete   compra transacción.

Pero SFSB no son simples y si usted no tiene necesidades que justifican su uso, mi consejo práctico sería seguir con la sesión HTTP (especialmente si todo esto es nuevo para usted). Por si acaso, ver:

• sin estado y con estado Enterprise Java Beans
• con estado EJB en aplicaciones web?

  

Así que de vuelta a la cuestión principal que veo escrito en la que JSF es una tecnología de presentación, por lo que no se debe utilizar para la lógica, pero parece que la opción perfecta para recoger la entrada del usuario.

Eso no es la lógica de negocio, que es la lógica de presentación.

  

Así que tengo múltiples niveles (...)

No. Es probable que haya un nivel de cliente, una capa de presentación, una capa de negocio, un nivel de datos. Lo que usted describe se parece más a las capas (ni siquiera estoy seguro). Ver:

• ¿Alguien puede explicar estas palabras: nivel de presentación, negocios Nivel, Nivel de Integración de Java EE con el ejemplo
?
• Spring, Hibernate, Java EE en la arquitectura de 3 niveles

  

¿Por qué es tan malo?

No sé, no sé lo que estás hablando :) Pero se debe probablemente sólo recopilar la información de múltiples páginas en forma de un grano de SessionScoped y llame a un Sin estado Bean de sesión (SLSB) al final del proceso.

Answer 2

  

1) ¿Por qué es llamado un bean de sesión, por lo que yo puedo ver que no tiene nada que ver con una sesión, que podría lograr el mismo mediante el almacenamiento de un POJO en una sesión.

Corrección: una sesión EJB no tiene nada que ver con una sesión HTTP. En EJB, dijo más o menos, el cliente es el contenedor de servlets y el servidor es el contenedor EJB (tanto en ejecución en un servidor web / aplicación). En HTTP, el cliente es el navegador web y el servidor es el servidor web / aplicación.

¿tiene más sentido ahora?

  

2) ¿Cuál es el punto de ser capaces de inyectar, si todo lo que voy a estar inyectando' es una nueva instancia de este SFSB entonces yo también podría utilizar un POJO?

El uso de EJB para las tareas de negocio transaccionales. Utilice una sesión en ámbito bean administrado a los datos específicos de la sesión HTTP tienda. Ninguno de los dos son de POJO por cierto. Sólo Javabeans.

  

¿Por qué no debería usar un grano de JSF SessionScoped para la lógica?

Si usted no está tomando ventaja de las tareas de negocio transaccionales y el EJB abstracción proporciona alrededor de él, a continuación, sólo lo hace en un grano de JSF sencilla logrado de hecho no es una mala alternativa. Esa es también la aproximación normal en aplicaciones básicas JSF. son, sin embargo por lo general a tomar las acciones lugar en un ámbito de petición bean gestionado en el que la sesión en ámbito uno se ha inyectado como un @ManagedProperty.

Sin embargo, puesto que ya está utilizando EJB, me pregunta si no había una razón específica para el uso de EJB. Si ese es el requisito de negocio de la mano superior, a continuación, que acababa de atenerse a ella. Al menos, su sesión-confusión ahora debe ser aclarado.

Answer 3

En caso de que no somos conscientes de ello, y como una pequeña contribución a las respuestas que tenga, de hecho podría anotate un SFSB con @SessionScoped, y CDI manejará el ciclo de vida del EJB ... Esto haría atar un EJB a la sesión HTTP que gestiona CDI. Sólo quiero hacerles saber, porque en su pregunta que 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 . . .

Además, se puede hacer lo que usted sugiere, pero depende de sus necesidades, hasta que los frijoles CDI reciben soporte de transacciones declarativa o prolongada persistencia contextos etc, se encontrará escribir mucho código repetitivo que haría su grano de menos limpio . Por supuesto, también puede utilizar marcos como la costura (ahora se mueve a DeltaSpike ) para mejorar ciertas capacidades de sus granos a través de sus extensiones.

Así que yo diría que sí, a primera vista se puede sentir que no es necesario el uso de un EJB con estado, pero ciertos casos de uso se pueden resolver mejor a través de ellos. Si un usuario añade un producto a su carro, y otro usuario agrega este mismo producto más adelante, pero sólo hay una unidad en stock, quien lo recibe? el que hace la compra más rápidamente? o el que se añade en primer lugar? ¿Qué pasa si usted desea acceder a su gestor de la entidad que persista un kart por si el usuario decide cerrar su navegador al azar o lo que si tiene transacciones que se generan varias páginas y desea cada paso que se sincronizan con el PP? (Para mantener una transacción abierta durante tanto tiempo no es aconsejable, pero tal vez podría haber una situación en la que esto es necesario?) Usted podría utilizar SLSB pero a veces es mejor y más limpio para utilizar un SFSB ..