Afinando escopos no JSF
Initializing the article…
Meu nome é Gabriel, sou Analista Desenvolvedor de Sistemas escrevo esse texto para batermos um papo informativo, quero interagir com você e aí vamos papear sobre escopos no Java Server Faces(JSF)?
Eu estava estudando sobre JSF, já o vira na faculdade, mas estava bem enferrujado, mas comecei a participar de um projeto a qual faço parte na empresa que trabalho, um projeto onde forma devs para várias tecnologias, tenho participação na formação Java FullStack, excelente para quem está começando, que é o meu caso, bom eu fui designado a desenvolver meu primeiro CRUD utilizando esse framework o JSF, então comecei criando os models as views e os famosos beans, usando os deveras conhecidos escopos do tipo RequestScoped.
Começando a Desenvolver és que surgem os Problemas. 😂
Isso mesmo galerinha comecei então a ter alguns problemas no meio do caminho…(novidade) rsrs.
Mas isso é assunto para tratarmos mais a frente, não vamos esquentar a cabeça, por hora é importante saber como se comporta o JSF diante das requisições, seu comportamento e do tipo “component-based”, basicamente é assim, a página irá buscar informação no Bean, cada Bean tem seu tipo de escopo conforme fora anotado.
Tudo é RequestScoped e SessionScoped ? 🤔
Ficou curioso? Então vem ver o meu relato!
Conforme as minhas pesquisas e estudos eu vir pessoas defendendo assiduamente o escopo do tipo SessionScoped, já vi outras defendendo o RequestScoped enfim, eu assistir e li muito nessa aventura, vir vários exemplos anotados com RequestScoped e outros usando o SessionScoped. Que tal vamos falar sobre isso? Assim você pode entender sobre os 3 tipos de escopos quais eram usados nas Versões 1x do JSF, e também sobre o 4º tipo adicionado a partir das versões 2x do JSF, os escopos criados com a chegada do CDI falaremos em outro post que irei deixar o link aqui, então se você quer entender melhor como funciona cada um desses escopos bem como também como utilizar, vem comigo, vamos mergulhar nessa aventura.
Bom, inicialmente para algo simples… (defina simples Gabriel), seria um (Envio de dados de um form com alguns valores) nesse caso utilizava escopos do tipo RequestScoped, para casos mais complexos utiliza-se um escopo com duração maior, no caso o SessionScoped. Mas isso inicialmente, porque a “coisa” toda ficou melhor, vamos logo deixando de teoria e ver uns exemplos práticos sobre cada um deles.
Como Utilizar as Anotações nos ManagedBeans? 🤔
Para utilizar algumas das anotações de escopos para os Beans, ex: @RequestScoped, @SessionScoped, @ApplicationScoped, @ViewScoped, basta apenas declarar uma das tais citadas acima na classe bean? Isso só foi possível a partir das versões do JSF 2x, antes disso era necessário declarar via arquivo xml, o faces-config. Agora está tudo mais fácil em? Vamos ao exemplo:
Abaixo temos os quatro escopos com as definições de cada um e recomendações de quando os utilizar:
@RequestScope: todos os objetos armazenados nesse escopo, ficam “vivos” apenas a uma requisição do ciclo de vida JSF, esse é outro assunto interessante, farei outro post explicando. Mas resumindo isso significa que a cada requisição HTTP, uma instância nova do ManagedBean é criada, dessa forma não tem informações sendo guardadas entre as requisições e as informações que foram submetidas anteriormente ao MaganedBean são descartadas, ou seja, não tem compartilhamento. O RequestScoped, tem o menor tempo de vida dentre todos os escopos, com isso as informações ficam pouco tempo em memória, afinal dura apenas uma requisição, por isso ele e sempre muito procurado por nós que nos preocupamos com performance, mas calma nada é absoluto, porem faz-se necessário entender cada escopo para saber aplicar nas situações certas, me acompanhe…
Uso Recomendado 👍
Uma boa utilização seria em telas onde não necessitem de informações extras referentes ao objeto que está sendo submetido na requisição, um exemplo seria na submissão de um formulário e ao fazer essa requisição o objeto fique pronto para ser persistido. Outra boa utilização seria em chamadas que não necessitem de chamadas Ajax. Ou mesmo na geração de relatório por ser ThreadSafe.
Aonde não é recomendado usar RequestScope? Imagine só uma aplicação que você precisa guardar o número de acessos, bom usando o RequestScope sempre vai ter apenas um acesso tendo em vista que dura apenas uma requisição as informações nesse escopo, ou mesmo uma aplicação onde seja necessário guardar informações de usuário durante a sessão, como esse Bean não dura um longo período isso ficariam bem errado usando RequestScope
Boa Prática 🤗
É importante saber que se não for definido um escopo ao ManagedBean o RequestScope e o padrão adotado, então por default será o escopo atribuído, porem e uma boa prática informar, pois, outros desenvolvedores forem analisar seu código, irão ter uma compreensão melhor do que está sendo feito.
@SessionScope: Essa cara se mantém por toda sessão da web, a sessão é definida pelo navegador em conjunto com o servidor, exemplificando se o usuário abrir dois navegadores terá então duas sessões ativas, tem o mesmo comportamento do HttpSession, todos os objetos. Muitas vezes esse escopo é usado em casos onde tem se a necessidade de manter o estado de objetos por toda sessão, mas isso é um perigo, pode acabar diminuindo a escalabilidade da aplicação se utilizado de forma desnecessária, pois cada objeto terá seu valor em memória, temos outras opções que muitas vezes são melhores, claro, cada caso é um caso, o fato que em muitas opções podemos usar o ViewScope, falaremos sobre ele no próximo tópico. Por isso a importância de entender sobre os escopos no JSF.
Uso Recomendado 👍
Uma boa utilização seria para o controle do que um determinado usuário pode ver na view(ex: usuários do operacional não pode ter acesso a view de finanças), ou mesmo para guardar informações do usuário, como, por exemplo, credenciais, login e senha, ou mesmo preferencias da página, também informações que necessitem ser utilizadas durante a sessão do usuário.
@ApplicationScope: Tudo armazenado nesse escopo permanece em uma instância na memória enquanto a aplicação estiver funcionando, bem-parecido com o Singleton, é importante saber que tudo é compartilhado entre os usuários que acessam a aplicação, com isso já podemos sentir o cheiro de coisa errada, caso utilizemos esse escopo para salvar informação de um certo usuário.
Uso Recomendado 👍
É interessante utilizar essa cara em casos que seja necessário prover funcionalidades que necessitem comunicação entre usuários, como parâmetros, valores, etc. Este escopo também é interessante para se trabalhar com lista de estados.
Boa Prática 🤗
É importante saber como esse escopo é muito usado para fornecer dados para toda aplicação, muitas vezes se faz necessário inicializá-lo antes de toda aplicação isso pode ser feito sim e é bem fácil fazer isso, basta colocar a seguinte configuração na declaração da anotação do escopo @ManagedBean(eager = true).
@ViewScope: Logo acima eu havia citado que em alguns casos ao invés do SessionScoped, poderíamos usar o ViewScoped, então chegou a hora de entendermos o por que, primeiro é importante saber que o ViewScoped foi criado para resolver justamente situações em que sempre tinha que se utilizar SessionScoped, nos casos que era necessário manter dados entre requisições, agora imagine em uma aplicação grande como não ficaria tantos beans na memória, já cheira logo a pouco escalável não? Então surgiu o ViewScoped que fica entre o SessionScoped e o RequestScoped, com ele podemos manter os dados durante as requisições necessárias, claro, desde que todas sejam realizadas para a mesma view, justamente isso que o torna diferente do escopo de sessão, pois caso seja executado uma requisição para uma view ou ManagedBean diferente, o escopo é limpo, e memoria liberada, uhuu pode comemorar, dessa forma objetos, não ficarão vivos por muito tempo empatando o lado da sua aplicação rsrs.
Uso Recomendado 👍
Bom já ficou claro que uma boa utilização para o ViewScoped seria nos casos em que é necessário executar muitas requisições para uma mesma view, exemplificando melhor posso ilustrar uma situação em que temos um dataTable e temos chamadas Ajax com dialogs, nesse caso manter esse dataTable com os dados enquanto o usuário está naquela view e interessante, pois dessa forma a cada novo dialogo não terá a necessidade de ir à base de dados buscar a informação. Agora claro nem tudo são flores, algumas situações podem dar errado por isso é importante entender bem esses escopos, vejamos um exemplo onde vários usuários (acessar) ao mesmo tempo, esse dataTable que citamos acima e fazem alterações nele, nesse caso se um usuário estiver com a view aberta a bastante tempo as alterações não irão refletir na view que ele está isso devido aos dados estarem em memória.
Com isso concluímos nosso aprendizado sobre annotations nos Mananged Beans e já podemos então colocar a mão no código e começar a testar, uhuu então boa gambiarra e até o próximo episódio. Prepare-se bons papos está por vim.
Lembrando que esse e um artigo básico inicial, existem outros tipos de escopos que valem a pena buscar, deixo essa task para você.
Bom código obrigado e nada de desistir, ok? 😜
