Nas versões do JSF 1.x, era possível trabalhar com os seguintes escopos: request, session e application. Com isso sempre que era necessário criar algo simples se utilizava o escopo request, já em casos mais complexos era necessária a utilização de algum escopo de maior duração, sendo utilizado na maioria destes casos, o session.
A partir do JSF 2, além dos três escopos já mencionados, foi incorporado um quarto escopo denominado ViewScoped, o qual será explicado juntamente com os demais neste post.
Para realizar as configurações referentes ao escopo possuimos duas opções:
utilizando a forma declarativa, via xml no arquivo de configurações do JSF (faces-config.xml):
Utilizando alguma das anotações @RequestScoped, @SessionScoped, @ApplicationScoped, @ViewScoped, acima da declaração do ManagedBean, sendo que esta possibilidade foi adicionada nas versões do JSF 2.x :
@ManagedBean
@RequestScoped
public class MyManagedBean {
// atributos e métodos do managed bean
}
Abaixo temos os quatro escopos com as definições de cada um e recomendações de quando os utilizar:
Request Scope: todos os objetos armazenados no escopo request, sobrevivem apenas a uma submissão ao ciclo de vida do JSF (os quais irei explicar em outro post). Com isso temos uma duração que condiz com a requisição sendo enviada ao servidor, e este devolvendo a resposta ao usuário que disparou a ação. Possui o menor tempo de vida dentre os escopos, desta forma, os objetos permanecem por pouco tempo em memória sendo esta liberada com maior frequência e com isso temos uma aplicação que tende a escalar melhor.
Não é recomendado em casos onde seja necessário manter os dados durante um longo período ou mesmo para compartilhar dados entre sessões de usuários. Em casos de submissão de dados simples, edição, entre outros, este escopo é o recomendado.
O escopo request é o padrão dos Managed Beans, logo ao não definir o escopo de seu ManagedBean, o padrão será request.
Session Scope: todos os objetos e atributos vinculados ao ManagedBean, sobreviverão durante toda a sessão do usuário. A sessão é definida pelo vinculo do navegador do usuário com o servidor. Desta forma, se usuário abrir dois navegadores, ele estará criando duas sessões com o servidor. Este escopo era muito utilizado nas versões do JSF 1.x, para se trabalhar em casos onde era necessário manter o estado de objetos, atualmente esta necessidade, muitas vezes, pode ser resolvida através do View Scope.
Recomendado em casos onde é necessário guardar informações do usuário ou mesmo dados de preferência deste, além de informações que possam ser utilizadas com frequência durante a sessão.
Deve-se ter cuidado, pois se utilizado com frequência e de maneira indevida, pode causar sérios problemas de desempenho.
Application Scope: tudo armazenado neste escopo permanece enquanto a aplicação estiver executando e é compartilhado entre todos os usuários. É recomendado sempre que for necessário guardar informações que podem ser utilizada por diversas partes da aplicação como parâmetros e também implementar funcionalidades para prover comunicação entre usuários. Este escopo também é interessante para se trabalhar com caches manuais de valores, como exemplo lista de estados.
View Scope: adicionado a partir da versão JSF 2, foi criado para resolver o problema de sempre utilizar session quando era necessário manter os dados entre requisições e que não onerasse tanto a aplicação. O View Scope oferece suporte ao modelo statefull do framework, onde é possível manter os dados durante quantas requisições forem necessárias, desde que todas estas sejam realizadas para a mesma view. Caso seja executado uma requisição para uma pagina e/ou ManagedBean diferente, o escopo é limpo, evitando assim que objetos não utilizados se mantenham vivos por muito tempo (caso que ocorria no escopo sessão).
Como já dito, é interessante no caso de se executar muitas requisições para uma mesma página, a exemplo disso podemos citar o carregamento de combos e a troca de abas.
Devemos atentar a questão de que o escopo somente será limpo (limpando os objetos da memória) no caso onde a requisição para outra view seja feita através de uma POST.
Esta apresentação reflete a opinião pessoal do autor sobre o tema, podendo não refletir a posição oficial do Portal Educação.
por Hermes Campos Soares
Tecnico em Informatica
Analista de Sistemas
Web Designer...
Web Developer..
UOL CURSOS TECNOLOGIA EDUCACIONAL LTDA, com sede na cidade de São Paulo, SP, na Alameda Barão de Limeira, 425, 7º andar - Santa Cecília CEP 01202-001 CNPJ: 17.543.049/0001-93