jsf - ¿Cómo elegir el alcance de frijol correcto?

jsf tags reference (2)

A partir de JSF 2.x hay 4 alcances de Bean:
@SessionScoped
@RequestScoped
@ApplicationScoped
@ViewScoped
Ámbito de la sesión: el alcance de la sesión persiste desde el momento en que se establece una sesión hasta la finalización de la sesión. Una sesión finaliza si la aplicación web invoca el método de invalidación en el objeto HttpSession, o si se agota.
RequestScope: El alcance de la solicitud es de corta duración. Se inicia cuando se envía una solicitud HTTP y finaliza después de que la respuesta se envía de vuelta al cliente. Si coloca un bean administrado en el ámbito de la solicitud, se creará una nueva instancia con cada solicitud. Vale la pena considerar el alcance de la solicitud si le preocupa el costo del almacenamiento del alcance de la sesión.
ApplicationScope: el alcance de la aplicación persiste durante toda la duración de la aplicación web. Ese alcance se comparte entre todas las solicitudes y todas las sesiones. Coloque los beans administrados en el ámbito de la aplicación si un solo bean debe compartirse entre todas las instancias de una aplicación web. El bean se construye cuando es solicitado por primera vez por cualquier usuario de la aplicación, y permanece activo hasta que la aplicación web se elimina del servidor de aplicaciones.
ViewScope: El alcance de vista se agregó en JSF 2.0. Un bean en el alcance de la vista persiste mientras se vuelve a mostrar la misma página JSF. (La especificación JSF usa el término vista para una página JSF). Tan pronto como el usuario navega a una página diferente, el bean queda fuera del alcance.
Elija el alcance que usted basado en su requisito.

Fuente: Core Java Server Faces 3rd Edition por David Geary & Cay Horstmann [Página nº. 51 - 54]

Noté que hay diferentes alcances de frijol como:

@RequestScoped @ViewScoped @FlowScoped @SessionScoped @ApplicationScoped

¿Cuál es el propósito de cada uno? ¿Cómo elijo un alcance adecuado para mi frijol?

Introducción

Representa el alcance (la vida útil) del bean. Esto es más fácil de entender si está familiarizado con el funcionamiento "bajo las coberturas" de una aplicación web de servlet básica: ¿Cómo funcionan los servlets? Creación de instancias, sesiones, variables compartidas y multiproceso .

`@Request/View/Flow/Session/ApplicationScoped`

Un bean @RequestScoped vida tan larga como un solo ciclo de solicitud / respuesta HTTP (tenga en cuenta que una solicitud Ajax cuenta como una sola solicitud HTTP). Un bean @ViewScoped vive siempre que esté interactuando con la misma vista JSF mediante devoluciones de datos que invocan métodos de acción que devuelven null / void sin ninguna navegación / redireccionamiento. Un bean @FlowScoped vive siempre que esté navegando a través de la colección especificada de vistas registradas en el archivo de configuración de flujo. Un bean @SessionScoped vida tan larga como la sesión HTTP establecida. Un bean @ApplicationScoped vive mientras se ejecuta la aplicación web. Tenga en cuenta que el @Model CDI es básicamente un stereotype para @Named @RequestScoped , por lo que se aplican las mismas reglas.

El ámbito a elegir depende únicamente de los datos (el estado) que el bean contiene y representa. Use @RequestScoped para formas / presentaciones simples y no ajax. Utilice @ViewScoped para vistas dinámicas habilitadas para ajax (validación basada en ajax, representación, cuadros de diálogo, etc.). Use @FlowScoped para el @FlowScoped de "asistente" ("cuestionario") de recopilación de datos de entrada distribuidos en varias páginas. Utilice @SessionScoped para datos específicos del cliente, como el usuario que ha iniciado sesión y sus preferencias (idioma, etc.). Utilice @ApplicationScoped para datos / constantes de toda la aplicación, como listas desplegables que son iguales para todos, o beans administrados sin variables de instancia y que solo tienen métodos.

El uso @ApplicationScoped un bean @ApplicationScoped para datos de sesión / vista / solicitud hará que se compartan entre todos los usuarios, de modo que cualquier otra persona puede ver los datos de los demás, lo que es simplemente erróneo. El uso @SessionScoped un bean @SessionScoped para ver / solicitar datos con alcance hará que se compartan entre todas las pestañas / ventanas en una sola sesión del navegador, por lo que el usuario final puede experimentar inconsistencias al interactuar con cada vista después de cambiar entre pestañas, lo que es malo para la experiencia del usuario. El uso indebido de un bean @RequestScoped para ver datos de ámbito de visualización haría que los datos de ámbito de vista se reinicializaran de manera predeterminada en cada devolución de datos (ajax), causando posiblemente formularios que no funcionan ( consulte también los puntos 4 y 5 aquí ). Abusar de un bean @ViewScoped para datos solicitados, de sesión o de aplicación, y abusar de un bean @SessionScoped para datos de ámbito de aplicación no afecta al cliente, pero ocupa innecesariamente la memoria del servidor y es ineficiente.

Tenga en cuenta que el alcance no debería ser elegido en función de las implicaciones de rendimiento, a menos que realmente tenga una huella de memoria baja y quiera quedarse sin estado; necesitaría usar exclusivamente frijoles @RequestScoped y jugar con los parámetros de solicitud para mantener el estado del cliente. También tenga en cuenta que cuando tiene una sola página JSF con datos de ámbito diferente, entonces es perfectamente válido colocarlos en beans de respaldo separados en un ámbito que coincida con el alcance de los datos. Los beans solo pueden acceder entre sí a través de @ManagedProperty en el caso de los beans gestionados por JSF o @Inject en el caso de los beans gestionados por CDI.

Ver también:

`@CustomScoped/NoneScoped/Dependent`

No se menciona en su pregunta, pero (legado) JSF también admite @CustomScoped y @NoneScoped , que rara vez se utilizan en el mundo real. El @CustomScoped debe referir una implementación personalizada del Map<K, Bean> en algún ámbito más amplio que haya invalidado el Map#put() y / o Map#get() para tener un control más preciso sobre la creación y / o destrucción del bean.

El JSF @NoneScoped y el CDI @Dependent básicamente viven tanto como una única evaluación EL en el bean. Imagine un formulario de inicio de sesión con dos campos de entrada que refieran una propiedad de bean y un botón de comando que refiera una acción de bean, por lo tanto, con un total de tres expresiones EL, se crearán efectivamente tres instancias. Uno con el nombre de usuario establecido, uno con la contraseña establecida y otro en el que se invoca la acción. Por lo general, desea utilizar este ámbito solo en beans que deberían vivir tanto como el bean en el que se está inyectando. Entonces, si se inyecta un @NoneScoped o @Dependent en un @SessionScoped , entonces vivirá tanto como el bean @SessionScoped .

Ver también:

Alcance flash

Como último, JSF también soporta el alcance flash. Está respaldado por una cookie de corta duración que está asociada con una entrada de datos en el ámbito de la sesión. Antes de la redirección, se establecerá una cookie en la respuesta HTTP con un valor que se asocia de forma única con la entrada de datos en el ámbito de la sesión. Después de la redirección, se comprobará la presencia de la cookie de alcance flash y la entrada de datos asociada con la cookie se eliminará del alcance de la sesión y se colocará en el alcance de solicitud de la solicitud redirigida. Finalmente la cookie será eliminada de la respuesta HTTP. De esta manera, la solicitud redirigida tiene acceso para solicitar datos de alcance que se prepararon en la solicitud inicial.

En realidad, esto no está disponible como un alcance de bean administrado, es decir, no existe tal cosa como @FlashScoped . El alcance del flash solo está disponible como un mapa a través de ExternalContext#getFlash() en beans administrados y #{flash} en EL.