SeamFramework.orgCommunity Documentation

Parte I. Beans

A especificação JSR-299 (CDI) define um conjunto de serviços complementares que ajudam a melhorar a estrutura do código da aplicação. CDI dispõe uma camada com um avançado ciclo de vida e um modelo de interação sobre os tipos de componentes Java existentes, incluindo os managed beans e Enterprise Java Beans. Os serviços da CDI fornece:

  • um ciclo de vida melhorado para objetos stateful, vinculados a contextos bem definidos,

  • uma abordagem typesafe para injeção de dependência,

  • interação com objetos através de um mecanismo de notificação de eventos,

  • uma melhor abordagem para associar interceptadores a objetos, juntamente com um novo tipo de interceptador, chamado de decorador, que é mais adequado para uso na resolução de problemas de negócio, e

  • um SPI para desenvolvimento de extensões portáveis para o contêiner.

The CDI services are a core aspect of the Java EE platform and include full support for Java EE modularity and the Java EE component architecture. But the specification does not limit the use of CDI to the Java EE environment. In the Java SE environment, the services might be provided by a standalone CDI implementation like Weld (see Seção 18.4.1, “Módulo CDI SE”), or even by a container that also implements the subset of EJB defined for embedded usage by the EJB 3.1 specification. CDI is especially useful in the context of web application development, but the problems it solves are general development concerns and it is therefore applicable to a wide variety of application.

Um objeto vinculado a um contexto de ciclo de vida é chamado de bean. CDI inclui suporte embutido para vários tipos diferentes de bean, incluindo os seguintes tipos de componente do Java EE:

  • managed beans, e

  • EJB session beans.

Tanto os managed beans quanto os EJB session beans podem injetar outros beans. Mas alguns outros objetos, que não são em si beans no sentido aqui utilizado, podem também ter beans injetados via CDI. Na plataforma Java EE, os seguintes tipos de componente podem ter beans injetados:

  • message-driven beans,

  • interceptadores,

  • servlets, filtros de servlet e escutadores de eventos servlet,

  • pontos de acesso e manipuladores de serviço JAX-WS, e

  • manipuladores de tag JSP e escutadores de evento em biblioteca de tag.

CDI livra o usuário de uma API desconhecida e da necessidade de reponder às seguintes questões:

  • Qual é o ciclo de vida deste objeto?

  • Quantos clientes simultâneos eu posso ter?

  • É multithread?

  • Como faço para obter acesso a ele a partir de um cliente?

  • Eu preciso explicitamente destruí-lo?

  • Onde devo manter referência a ele quando não estiver usando-o diretamente?

  • Como posso definir uma implementação alternativa, de modo que a implementação possa variar em tempo de implantação?

  • Como devo proceder no compartilhamento deste objeto com outros objetos?

CDI é mais do que um framework. É um completo e rico modelo de programação. O tema de CDI é baixo acoplamento com tipagem forte. Vamos estudar o que esta frase significa.

Um bean especifica apenas o tipo e a semântica de outros beans que ele dependa. Ele não precisa ser consciente do ciclo de vida atual, implementação concreta, modelo de threading ou outros clientes de qualquer bean que ele venha a interagir. Melhor ainda, a implementação concreta, ciclo de vida e o modelo de threading de um bean podem variar de acordo com o cenário de implantação, sem afetar qualquer cliente. Este baixo acoplamento torna seu código mais fácil de manter.

Eventos, interceptadores e decoradores melhoram o baixo acoplamento inerente a este modelo:

  • notificadores de eventos desacoplam os produtores de eventos dos consumidores dos eventos,

  • interceptadores desacoplam questões técnicas da lógica de negócios, e

  • decoradores permitem que questões de negócios sejam compartimentadas.

O que é ainda mais poderoso (e confortável) é que CDI oferece todas essas facilidades de uma maneira typesafe. CDI nunca confia em identificadores baseados em strings para determinar como os objetos se relacionam. Em vez disso, CDI utiliza a informação de tipagem que já está disponível no modelo de objeto Java, aumentada com um novo padrão de programação, chamada de anotações qualificadoras, para unir os beans, suas dependências, seus interceptadores e decoradores, e seus consumidores de eventos. A utilização de descritores XML é minimizada para simplesmente informação específica de implantação.

Mas CDI não é um modelo de programação restritivo. Ele não diz como você deve estruturar sua aplicação em camadas, como você deve lidar com a persistência, ou qual framework web você tem que usar. Você terá que decidir esses tipos de coisas por conta própria.

CDI ainda provê um SPI abrangente, permitindo que outros tipos de objeto definidos pelas futuras especificações Java EE ou por frameworks de terceiros sejam transparentemente integrados com CDI, tirando proveito dos serviços de CDI e interagindo com qualquer outro tipo de bean.

A CDI foi influenciada por inúmeros frameworks Java existentes, incluindo Seam, Guice e Spring. Entretanto, CDI tem suas próprias e bem distintas características: mais typesafe que o Seam, mais stateful e menos centrada em XML que o Spring, mais hábil em aplicações web e corporativas que o Guice. Mas poderia ter sido nada disso sem a inspiração vinda dos frameworks mencionados e a grande quantidade de colaboração e trabalho duro do JSR-299 Expert Group (EG).

Finalmente, CDI é um padrão do Java Community Process (JCP). Java EE 6 requer que todo servidor de aplicação compatível forneça suporte para JSR-299 (até mesmo no web profile).