Anteriormente ya hemos visto que cuando se declara un bean, tenemos que darle un scope: application, session, view, request, none. Un scope es un mapeo entre nombres y objetos que se almacena durante un determinado periodo de tiempo. En este post vamos a explicar cada uno de ellos.
Si declaramos el bean desde el fichero faces-config.xml, indicamos el scope en <managed-bean-scope> y si queremos hacerlo con anotaciones, utilizaremos @{Application,Session,View,Request,None}Scoped
Application
Si declaramos el bean desde el fichero faces-config.xml, indicamos el scope en <managed-bean-scope> y si queremos hacerlo con anotaciones, utilizaremos @{Application,Session,View,Request,None}Scoped
Application
Con este scope, se guarda la información durante toda la vida de la aplicación web, independientemente de todas las peticiones y sesiones que se realicen. Este bean se instancia con la primera petición a la aplicación y desaparece cuando la aplicación web se elimina del servidor. Si queremos que el bean se instancie antes de que se muestre la primera página de la aplicación, usamos la propiedad eager a true.
@ManagedBean(eager=true) ó <managed-bean eager="true">
Session
Como su mismo nombre indica, este scope guarda la información desde que el usuario comienza una sesión hasta que ésta termina (porque el tiempo expiró o se invocó al método invalidate sobre un objeto HttpSession).
HTTP es un protocolo sin estado, y por tanto, una vez que se envía una petición al servidor y éste responde, no se guarda ninguna información sobre esta transición. Esto no es siempre adecuado en aplicaciones de lado de servidor, ya que es normal que necesiten ir guardando el estado. Para ello, podemos utilizar:
- Cookies: pares nombre-valor que el servidor envía al usuario, confiando en que en posteriores peticiones se la vaya "devolviendo"
- URL rewriting: añade un identificador de sesión a la URL
Los beans de sesión no son single-threaded. Los usuarios podrían mandar peticiones desde varios navegadores a la vez, manejada cada una de ellas por un hilo diferente. Si necesitamos que sea thread-safe, tenemos que implementar mecanismos de bloqueo.
View (a partir de JSF 2.0)
El scope dura desde que se muestra una página JSF al usuario hasta que el usuario navega hacia otra página. Es muy útil para páginas que usan AJAX.
Request
Comienza cuando se envía una petición al servidor y termina cuando se devuelve la respuesta al usuario. Esto hace que se cree una instancia del bean asociado para cada petición. Los mensajes de estado y de error que se muestran al usuario son buenos candidatos a ser request, ya que se muestran una vez que el servidor devuelve la respuesta. Son single-threaded y por lo tanto, thread-safe.
None
Los beans se instancian cuando son necesitados por otros beans, y se eliminan cuando esta necesidad desaparece.
Desde JSF 2.0, también se permite crear scopes customizados (@CustomScoped) donde el tiempo que dura este scope lo definimos nosotros. Por tanto la aplicación se vuelve responsable de ir eliminando las instancias de los beans del mapeo.
Cuando a un método le asocias la anotación @PostConstruct se ejecutará después de la inicialización del bean pero antes de que sea guardado en su scope correspondiente.
Si al método le asocias la anotación @PreDestroy se ejecutará justo antes de que el bean sea eliminado del scope.
Como buenas prácticas, se recomienda utilizar siempre el menor scope que necesite el bean, para evitar así posibles problemas de memoria al tener que almacenar más información de la necesaria.
@ManagedBean(eager=true) ó <managed-bean eager="true">
Session
Como su mismo nombre indica, este scope guarda la información desde que el usuario comienza una sesión hasta que ésta termina (porque el tiempo expiró o se invocó al método invalidate sobre un objeto HttpSession).
HTTP es un protocolo sin estado, y por tanto, una vez que se envía una petición al servidor y éste responde, no se guarda ninguna información sobre esta transición. Esto no es siempre adecuado en aplicaciones de lado de servidor, ya que es normal que necesiten ir guardando el estado. Para ello, podemos utilizar:
- Cookies: pares nombre-valor que el servidor envía al usuario, confiando en que en posteriores peticiones se la vaya "devolviendo"
- URL rewriting: añade un identificador de sesión a la URL
Los beans de sesión no son single-threaded. Los usuarios podrían mandar peticiones desde varios navegadores a la vez, manejada cada una de ellas por un hilo diferente. Si necesitamos que sea thread-safe, tenemos que implementar mecanismos de bloqueo.
View (a partir de JSF 2.0)
El scope dura desde que se muestra una página JSF al usuario hasta que el usuario navega hacia otra página. Es muy útil para páginas que usan AJAX.
Request
Comienza cuando se envía una petición al servidor y termina cuando se devuelve la respuesta al usuario. Esto hace que se cree una instancia del bean asociado para cada petición. Los mensajes de estado y de error que se muestran al usuario son buenos candidatos a ser request, ya que se muestran una vez que el servidor devuelve la respuesta. Son single-threaded y por lo tanto, thread-safe.
None
Los beans se instancian cuando son necesitados por otros beans, y se eliminan cuando esta necesidad desaparece.
Desde JSF 2.0, también se permite crear scopes customizados (@CustomScoped) donde el tiempo que dura este scope lo definimos nosotros. Por tanto la aplicación se vuelve responsable de ir eliminando las instancias de los beans del mapeo.
Cuando a un método le asocias la anotación @PostConstruct se ejecutará después de la inicialización del bean pero antes de que sea guardado en su scope correspondiente.
Si al método le asocias la anotación @PreDestroy se ejecutará justo antes de que el bean sea eliminado del scope.
Como buenas prácticas, se recomienda utilizar siempre el menor scope que necesite el bean, para evitar así posibles problemas de memoria al tener que almacenar más información de la necesaria.
Comentarios
Publicar un comentario