Para ajudar nesses questionamentos a resposta é DeltaSpike. É uma biblioteca cujo objetivo principal foi unificar as diferentes funcionalidades existentes das mais diversas bibliotecas que auxiliam nas tarefas diárias do desenvolvedor. Além disso, ele pretende ser a para extensões ligadas principalmente ao JavaEE. Basicamente é um junção de forças, ao invés de cada um fazer a sua solução, os commiters dos projetos citados anteriormente se uniram.
Autor(a)
lacerdaph
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
O projeto possui uma api extensa, passando por testes, validação, ajuda para ter acesso aos contextos HTTP, criação de Repositórios, até mesmo uma integração com o Quartz. Enfim, muitas features interessantes para facilitar o seu trabalho, inclusive se você já estiver em um Application Server, que mesmo com a ótima versão do JavaEE 7, ainda possui alguns gaps, como a parte de segurança. Seria impossível cobrir todas elas, até porque desconheço boa parte, mas tenho certeza que você escreverá nos comentários as features que está usando para debatermos.
A configuração inicial do DeltaSpike é bem simples, basicamente é adicionar dependências no pom.xml. Como o projeto é divido por módulos, o único realmente necessário é o core, o resto é adicionado de acordo com a necessidade do desenvolvedor. Vamos para o código então.
Supondo que você esteja em um Servlet Container, o primeiro passo a ser feito é prover um EntityManager para o DeltaSpike poder trabalhar. Com CDI, basta usar uma fábrica:
Pronto, vamos pesquisar alguns dados de usuário. Para isso, precisamos criar um repositório e suas queries. O modulo data tem um suporte muito parecido com o framework Esfinge, basta montar o nome do método com um formato pré-definido e a query será gerada dinamicamente
Ainda relacionado ao Banco de Dados, nos códigos que precisamos de transação, a solução era chamar diretamente o entityManager.getTransaction().begin() ou criar na mão interceptadores CDI para criar transações demarcadas. O módulo JPA já oferece esse serviço, basta adicionar o interceptador no beans.xml e anotar os métodos que necessitam de transação com @Transactional (importe do pacote deltaSpike). O módulo também oferece um suporte interessante para Extended Persistence Context.
No aspecto de segurança, o JavaEE deixa muito a desejar, então o módulo do projeto oferece serviços interessantes, por exemplo, determinados métodos na sua aplicação só podem ser acessos caso o usuário tenha determinado perfil. Criamos uma anotação para identificar essa regra:
Criamos um classe para fazer a regra de negocio, perceba que o UsuarioLogado é um classe provida pelo CDI:
public class AutorizadorCritico { @Secures @Critico public boolean conferirPerfil(InvocationContext invocationContext, BeanManager manager, UsuarioLogado usuarioLogado) throws Exception { return usuarioLogado.isAdministrador()? true : false; }
@Produces @Critico @Named("fornecedores") public List<Fornecedor> listaFornecedores() { return todosFornecedores.listar(); } }
Por fim, o módulo de JSF oferece vários recursos, talvez o mais interessante seja uma nova gama de escopos. Um cenário comum em aplicações que usam esta tecnologia é o cadastro baseado em wizards, no qual há navegação por mais de uma tela. Apesar das novas novidades da versão 2.0 do framework, fazer isso em JSF não costuma ser muito trivial. Você pode usar o @ViewScoped, o @ConversationScoped do CDI ou até mesmo o Flash scope, mas a solução que eu achei mais conveniente é o @ViewAcessScoped do DeltaSpike.
Temos um cadastro no qual a primeira página é a listagem dos elementos e quando um elemento é selecionado, ocorre uma navegação para a página de edição. As duas páginas possuem referência para o mesmo BackingBean. Quando selecionamos um item na página de listagem, queremos que este item ainda fique ativo na página de edição. Se usássemos o @ViewScope do JSF, quando ocorre a navegação, o BackingBean seria criado novamente, perdendo a referência para o item selecionado.
O @ViewAccessScoped resolve esse problema. A definição é muito boa:
However, sometimes you need beans with a lifetime which is as long as needed and as short as possible - which are terminated automatically (as soon as possible)
. O escopo mantém um objeto ativo enquanto estiver referência para ele. Exemplificando:
Primeira página de listagem: #{usuarioBean.usuarios} e #{usuarioBean.editar(usuario)}
@ViewAcessScoped@ManagedBeanclassUsuarioBean {
}
Já na segunda página de edição temos a referência #{usuarioBean.usuarioSelecionado.nome}. Aqui o objeto UsuarioBean ainda está ativo e só irá morrer quando o usuário navegar para uma próxima página em que não haja referência para este ManagedBean.
The simple rule is, as long as the bean is referenced by a page - the bean will be available for the next page (if it’s used again the bean will be forwarded again)
.
Por incrível que pareça ainda recebo muitos questionamentos em sala sobre o Seam, e nas minhas aulas toda vez que eu falo sobre o DeltaSpike os alunos costumam gostar, espero que agora ainda mais. Você pode se inteirar mais sobre essas tecnologias com nossos cursos, onde sempre debatemos as novidades e outras opções. E você, gostou de alguma feature? Já utiliza? Não esqueça de deixar seu comentário.
