Injeção de dependências em Java EE usando @Inject, @EJB e @Resource ?

Olá pessoal, hoje iremos analisar o uso das annotations @Inject, @EJB @Resource, na injeção de componentes gerenciados.

Componentes Gerenciados 


Componentes gerenciados são objetos que possuem seu ciclo de vida gerenciado por um ambiente, ou seja, nos desenvolvedores não temos que se preocupar com lógicas de criação, infraestrutura e destruição dos objetos.

Na plataforma Java, é muito comum o trabalho com objetos gerenciados, um exemplo são os famosos EJBs, estes objetos possuem seu ciclo de vida controlado pelo Contêiner Java EE, os EJBs possuem uma infraestrutura complexa, com Segurança, Acesso Distribuído, Thread Safe, Transações, entre outras funcionalidades.

Além dos EJBs, temos vários outros objetos e componentes que são gerenciados pelo Contêiner, vamos listar alguns exemplos:

  • JMS:  A trabalhar com fila de mensagens em um ambiente Java EE, temos a fila disponibiliza e gerenciada pelo Contêiner, e nós somos responsáveis por criar os produtores e consumidores de mensagens;
  • CDI: Uma das grandes novidades do Java EE 6 com certeza foi o CDI (Context Dependency Injection), antes para ter um objeto gerenciado, tínhamos que criar um EJB, mas não é sempre que precisamos de um objeto tão robusto, a momentos que precisamos criar um simples POJO, que terá seu ciclo de vida gerenciado, e irá ser associado em algum escopo como: Request, Session ou Application;
  • DataSource: Um DataSource é um exemplo de componente gerenciado que acompanha o Java EE há muito tempo, é uma forma de criamos uma conexão com uma fonte de dados e deixar o Contêiner gerenciar a abertura e fechamento das conexões, muito comum em aplicações que usam persistência através de JDBC.

Injeção de Dependência


Uma dependência é quando um objeto precisa de outro para existir, ou seja, precisa de outro para funcionar e executar uma funcionalidade.

Mas como podemos injetar uma dependência dentro das nossas classes ?


De várias formas, mas cada uma delas pode deixar o código com alto ou baixo acoplamento, para seguir as boas práticas de Orientação a Objetos, uma boa classe deve focar na alta coesão e baixo acoplamento.

Onde entra a Injeção de Dependência ? 


 A Injeção de Dependência é uma forma de Inversão de Controle que visa deixar sua classe desacopladas de suas dependências, ou seja, ao invés de criar explicitamente o objeto ou chamar uma Factory, ela apenas recebe as dependências já inicializadas e prontas para o uso.

Injeção de Objetos Gerenciados


Quando utilizar @Inject ?


A annotation @Inject pode ser usada para os seguintes tipos de objetos:
  • POJO (CDI);
  • EJBs (@Local, @LocalBean e no-interface EJB);
  • Aplicações rodando em Contêiner Web Profile.
Exemplo do uso de @Inject para injetar um POJO gerenciado.

Mesmo os EJBs tendo sua própria annotation de injeção, nos casos acima, podemos usar o @Inject, visando deixar o código mais simples e de fácil migração entre POJO e EJB.

Quando utilizar @EJB ?


annotation @EJB pode ser usada para os seguintes tipos de objetos:
  • EJBs (@Local, @LocalBean e no-interface EJB);
  • EJBs (@Remote).
Exemplo do uso de @EJB para injetar um EJB Remote ou Local.

Esta annotation diferente do @Inject é de uso exclusivo de EJBs, não sendo válido o uso com POJO gerenciados.

Quando utilizar @Resource ?


A annotation @Resource é utilizada para objetos que não se enquadram nos itens anteriores, vamos analisar alguns exemplos:
  • DataSource (Conexão com fonte de dados);
  • SessionContext (Contexto de execução dos EJBs);
  • MessageDrivenContext (Contexto de execução dos MDBs);
  • UserTransaction (Manipular transações de EJBs com tipo BMT);
  • JMS (Manipular filas Queue ou Topic).
Exemplo do uso de @Resource para injetar recursos gerenciados.

Há ainda várias outras aplicações para a annotation @Resource, ela pode também injetar referências para EJBs, Sessões de envio de e-mails, e valores de entrada de ambiente, entre outras coisas, ela é sem dúvida uma das mais importantes da plataforma Java EE.

Agora sabemos como, onde, e quando, aplicar as principais annotations da Plataforma Java EE.

Até a próxima.

Como escolher um Framework para o meu projeto ?

Olá pessoal, hoje iremos abordar um assunto muito interessante, que é a escolha de um Framework, com certeza muitos desenvolvedores e arquitetos já ficaram com dúvidas na hora de tomar esta decisão tão importante, e que pode influenciar no sucesso do projeto.

Vou listar algumas práticas e experiências que adquiri nesses últimos anos, onde fui responsável por estas escolhas, iremos focar na plataforma Java, mas o processo de definição e escolha de APIs e Frameworks, pode ser adotado em qualquer outra linguagem, pois são passos que independente de tecnologia, ajudam a tomar as melhores decisões.

Devemos Usar um Framework ?

A necessidade do mercado por softwares evoluiu muito com o passar dos anos, hoje temos sistemas operando em quase todas as áreas: Financeira, Médica, Jurídica, entre outras, com toda essa demanda, o setor de desenvolvimento teve que evoluir para acompanhar a alta procura por sistemas em um curto prazo.

Os Frameworks entram nesse ponto, eles ajudam propondo soluções para problemas recorrentes que aparecem ao desenvolver sistemas diversos, exemplos:
Quando adotamos algum framework para desenvolver algumas camadas do nosso software, conseguimos muito benefícios, tais como: reduzir o tempo de desenvolvimento, aumentar a qualidade, reuso de funcionalidades, entre outros.

Como Escolher um Framework ?

Com certeza esse é um tópico que irá reunir muita discussão, pois a escolha de um framework, é algo que depende de vários fatores, vou citar alguns que podem ajudar na hora da escolha:
  • Suporte do Mantenedor
    • É importante que o desenvolvedor/empresa que desenvolveu o framework, dê suporte e seja ativo na comunidade.
  • Suporte da Comunidade
    • É muito bom quando o framework escolhido é bem aceito pela comunidade, seja em fóruns de discussão, em blogs, entre outros meios, assim podemos tirar dúvidas e esclarecer tópicos que aparecem no decorrer do desenvolvimento.
  • Conhecimento da Equipe / Curva de Aprendizado
    • É importante que a equipe tenha conhecimento sobre o framework escolhido;
    • Na escolha do framework, pode acontecer de que membros da equipe não o conheça, com este cenário, qual tempo um desenvolvedor vai levar para aprender detalhes funcionais do framework ?
  •  Protótipo
    • Antes de homologar um framework é muito importante desenvolver um Protótipo, assim podemos realizar testes funcionais e analisar se o mesmo irá atender aos requisitos do software
  • Atende aos Requisitos ?
    •  Para responder a esta pergunta, é fundamental os itens anteriores, pois com todos eles documentados conseguimos de forma clara e objetiva a resposta.

Não Existe Bala de Prata ?

É muito comum as empresas adotarem um framework como padrão, mas até onde isso é uma vantagem ou desvantagem ?

Vou listar abaixo alguns pontos dessa abordagem:

  • Vantagens
    • Melhor reuso de funcionalidades;
    • Membros da equipe podem focar seus estudos no framework, assim temos uma equipe mais preparada tecnicamente;
  • Desvantagens
    • Utilização de um framework X onde o Y seria mais adequado;
      •  Exemplo: Em uma aplicação Web que usa serviços REST, usar um framework Component Based onde um Action Based seria mais adequado.
    • Criar funcionalidades externas as propostas pelo framework, devido ao mesmo não atender aos requisitos de um novo software da empresa.

Conclusão

Como mencionei anteriormente, este é um assunto muito complexo em arquitetura de aplicações, porque pode trazer muitas consequências ao projeto, então é importante que a decisão final seja baseada em vários itens que comprovem que o framework escolhido, irá realmente atender aos requisitos do software que será desenvolvido.

Até a próxima.