CDI: Não use @Inject e @ManagedBean nas suas classes

Algumas semanas atrás tive uma experiência bem estressante e chata ao misturar as anotações do JSF com as anotações do CDI. Apesar de saber que EM TEORIA eu não deveria fazer isso eu acabei fazendo e percebendo o problema NA PRÁTICA.

O problema ocorria quando minha página processava uma EL (Expression Language) que apontava para um managed bean anotado com @ManagedBean e tinha suas dependências injetadas pelo CDI através da anotação @Inject… nesse momento a injeção não ocorria. Sendo mais específico, simplesmente o container (qual deles? JSF ou CDI?) injetava null no atributo da classe. O código era semelhante a este:

@ManagedBean
public class AlunosBean {

    @Inject
    private AlunosDao dao;

}

A coisa fica ainda mais feia quando misturava os escopos do CDI com o escopos do JSF. Imagina um managed bean sendo instanciado trocentas vezes? Pois é…

Depois de muito ler e discutir com amigos que sacam mais de CDI do que eu, como o Raphael Lacerda e Daniel Cunha, eu percebi que NÃO era uma boa prática misturar as anotações. Para você entender mais a fundo do que estou falando eu bloguei no blog da TriadWorks sobre isso. Você pode ler o post completo no link abaixo:

>>> NÃO misture anotações do JSF com as anotações do CDI

O post fala um pouco sobre meu problema e de quebra ensina como você pode migrar seus managed beans do JSF para beans do CDI. Onde com certeza essa é a melhor escolha que você poderia tomar.

Enfim, uma experiência interessante que quis compartilhar.

Criando anotações customizadas com Spring

Não é incomum que com o passar do tempo nossas classes fiquem repletas de anotações de diferentes categorias do seu framework IoC/DI, como Spring ou CDI. Estas anotações vão desde controle transacional, segurança, monitoramento e até logging. Se não tomarmos cuidado nós acabamos com muita duplicação de código de metadados e pouca legibilidade.

Para resolver isso, desde o Spring 3.0 nós podemos criar nossas próprias anotações com um significado mais próximo da nossa arquitetura ou mesmo negócio. Essa técnica de criar anotações com semântica é chamado de Stereotypes, ou do português, estereótipos.

Entender bem o conceito de estereótipos e saber estendê-lo é muito importante para arquitetos e desenvolvedores sêniors que almejam ter um melhor controle de como as classes da aplicação são registradas no container do Spring e procuram uma melhor manutenção do código a médio-longo prazo.

Criando e gerenciando objetos de terceiros com Spring e @Bean

Umas das premissas mais importantes quando trabalhamos com algum framework IoC/DI, como Spring ou CDI, é delegar a criação e o gerenciamento dos objetos para seus containers. Isso permite que nosso código seja mais flexível e menos acoplado a lógica de criação de objetos complexos ou de terceiros.

Assim como a anotação @Produces do CDI, o Spring desde sua versão 3.0 nos permite obter o mesmo comportamento através da anotação @Bean. A idéia é a mesma, criar objetos caros, complexos ou de outros frameworks e registrá-los no container para que eles possam ser injetados como dependências noutras classes do sistema.

Escrevi um artigo no blog da TriadWorks sobre o assunto com mais detalhes sobre a anotação @Bean e suas vantagens. Vale a pena a leitura e uso da prática!