java - tutorial - porque usar jsf
¿Por qué JSF guarda el estado de los componentes de la interfaz de usuario en el servidor? (1)
¿Por qué JSF necesita guardar el estado de los componentes de la interfaz de usuario en el lado del servidor?
Porque HTTP es sin estado y JSF tiene estado. El árbol de componentes JSF está sujeto a cambios dinámicos (programáticos). JSF simplemente necesita saber el estado exacto tal como era cuando el formulario se había mostrado al usuario final, de modo que puede procesar todo el ciclo de vida JSF basándose en la información proporcionada por el árbol de componentes JSF original cuando el formulario ha sido enviado nuevamente a el servidor. El árbol de componentes proporciona información sobre los nombres de los parámetros de solicitud, los convertidores / validadores necesarios, las propiedades de bean gestionadas encuadernadas y los métodos de acción.
¿Hasta qué punto JSF guarda el estado de los componentes de la interfaz de usuario en el servidor y cuándo se elimina exactamente la información de estado del componente de la interfaz de usuario de la memoria del servidor?
Esas dos preguntas parecen reducirse a lo mismo. De todos modos, esto es específico de la implementación y también depende de si el estado se guarda en el servidor o cliente. Una implementación un poco decente lo eliminará cuando haya expirado o cuando la cola esté llena. Mojarra, por ejemplo, tiene un límite predeterminado de 15 vistas lógicas cuando el ahorro de estado se establece en sesión. Esto se puede configurar con el siguiente parámetro de contexto en web.xml :
<context-param>
<param-name>com.sun.faces.numberOfLogicalViews</param-name>
<param-value>15</param-value>
</context-param>
Consulte también Preguntas frecuentes sobre Mojarra para otros parámetros específicos de Mojarra y esta respuesta relacionada com.sun.faces.numberOfViewsInSession vs com.sun.faces.numberOfLogicalViews
Como un usuario conectado en la aplicación navega por las páginas, ¿el estado de los componentes seguirá acumulándose en el servidor?
Técnicamente, eso depende de la implementación. Si está hablando de navegación de página a página (solo solicitudes GET), Mojarra no guardará nada en sesión. Sin embargo, si son solicitudes POST (formularios con enlaces de comando / botones), Mojarra guardará el estado de cada formulario en sesión hasta el límite máximo. Esto permite que el usuario final abra múltiples formularios en diferentes pestañas del navegador en la misma sesión.
O bien, cuando el ahorro de estado se establece en el cliente, entonces JSF no almacenará nada en la sesión. Puede hacerlo mediante el siguiente parámetro de contexto en web.xml :
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
Luego se serializará en una cadena cifrada en un campo de entrada oculto con el nombre javax.faces.ViewState del formulario.
No entiendo cuál es el beneficio de mantener el estado del componente UI en el lado del servidor. ¿No es suficiente pasar los datos validados / convertidos a los beans administrados? ¿Puedo / debería tratar de evitarlo?
Eso no es suficiente para garantizar la integridad y la solidez de JSF. JSF es un marco dinámico con un único punto de control de entrada. Sin una gestión estatal, uno podría falsificar / piratear solicitudes HTTP de cierta manera (por ejemplo, manipular atributos disabled , de readonly y rendered ), para permitir que JSF haga cosas diferentes, y potencialmente peligrosas. Incluso sería propenso a ataques de CSRF y phishing.
¿Y no consumirá demasiada memoria en el lado del servidor si hay miles de sesiones simultáneas de usuarios? Tengo una aplicación donde los usuarios pueden publicar blogs sobre ciertos temas. Estos blogs son bastante grandes. Cuando haya una publicación o solicitud para ver los blogs, los blogs grandes se guardarán como parte del estado de los componentes. Esto consumiría demasiada memoria. ¿No es esto una preocupación?
La memoria es particularmente barata. Simplemente dele al servidor de aplicaciones suficiente memoria. O si el ancho de banda de la red es más barato para usted, simplemente cambie el estado de ahorro al lado del cliente. Para encontrar la mejor coincidencia, simplemente estrese y perfile su aplicación web con la cantidad máxima esperada de usuarios simultáneos y luego dele al servidor de aplicaciones 125% ~ 150% de la memoria máxima medida.
Tenga en cuenta que JSF 2.0 ha mejorado mucho en la gestión estatal. Es posible guardar el estado parcial (por ejemplo, solo se guardará la <h:form> lugar de todo el contenido de <html> hasta el final). Mojarra, por ejemplo, hace eso. Un formulario promedio con 10 campos de entrada (cada uno con una etiqueta y un mensaje) y 2 botones no tomaría más de 1 KB. Con 15 vistas en sesión, no debería ser más de 15 KB por sesión. Con ~ 1000 sesiones simultáneas de usuarios, no deberían ser más de 15 MB.
Su preocupación debería centrarse más en los objetos reales (beans administrados y / o incluso entidades de DB) en el ámbito de la sesión o la aplicación. He visto muchos códigos y proyectos que innecesariamente duplican toda la tabla de la base de datos en la memoria de Java en el sabor de un bean con ámbito de sesión donde se usa Java en lugar de SQL para filtrar / agrupar / organizar los registros. Con ~ 1000 registros, eso pasaría fácilmente a más de 10MB por sesión de usuario .
¿Hasta qué punto JSF guarda el estado de los componentes de la interfaz de usuario en el lado del servidor y cuándo se elimina exactamente la información de estado del componente de la interfaz de usuario de la memoria del servidor? Como un usuario conectado en la aplicación navega por las páginas, ¿el estado de los componentes seguirá acumulándose en el servidor?
No entiendo cuál es el beneficio de mantener el estado de los componentes de la interfaz de usuario en el servidor. ¿No es suficiente pasar los datos validados / convertidos a los beans administrados? ¿Puedo o debo tratar de evitarlo?
¿Eso no consume demasiada memoria en el servidor, si hay miles de sesiones simultáneas de usuarios? Tengo una aplicación donde los usuarios pueden publicar blogs sobre ciertos temas. Estos blogs son bastante grandes. Cuando haya una publicación o solicitud para ver los blogs, ¿se guardarán los datos de esta gran página como parte del estado de los componentes? Esto consumiría demasiada memoria. ¿No es esto una preocupación?
Actualización 1:
Ahora, ya no es necesario guardar el estado mientras se usa JSF. Una implementación de JSF sin estado de alto rendimiento está disponible para su uso. Vea este blog y esta pregunta para obtener detalles relevantes y discusión. Además, hay un issue abierto para incluir en las especificaciones JSF, una opción para proporcionar un modo sin estado para JSF. (PD Considere votar por los problemas issue y this si esta es una característica útil para usted).
Actualización 2 (24-02-2013):
¡Una gran noticia de que Mojarra 2.1.19 está fuera con modo sin estado !
Mira aquí:
http://weblogs.java.net/blog/mriem/archive/2013/02/08/jsf-going-stateless?force=255