lindbergframework - Plug and Use: janeiro 2012

Um conceito importante abordado por muitos frameworks consolidados na comunidade java, como o spring, é o de inversão de controle para o tratamento de injeção de dependências. Esse conceito propõe a transferência de responsabilidade para a criação de beans no projeto fazendo com que o controle sobre a criação, gerenciamento e injeção de dependências destes beans não fique a cargo do programador e seja invertido para um container ou qualquer outro componente que possa tomar controle sobre a execução.

O lindbergframework precisa em muitos casos intervir e customizar a criação de beans para aplicar correta e eficientemente injeção de dependência nos mesmos. Uma outra necessidade de intervenção na criação de beans é para usar diversos tipos de proxies de aspecto para vários fins, como por exemplo no gerenciamento de transações via annotation. Para fazer isso, o lindbergframework aplica um proxy sobre o bean que gerenciará todo o processo de transação de forma transparente. Mas para tal, é necessário que o controle de criação dos beans seja invertido para o LDIC (Lindberg Dependency Injection Container). Toda a parte do gerenciamento de transações do framework será detalhada mais a frente quando a parte de persistência for abordada.

Um framework já consolidado que poderia ter sido adotado é o spring por exemplo, mas isso obrigaria que todo projeto que usasse o lindbergframework também tivesse que usar o spring. Para solucionar o problema um mecanismo de inversão de controle foi criado de forma independente e exclusiva para o lindbergframework. Caso você deseje mesmo assim usar spring em seu projeto o lindbergframework no módulo integration fornece integração com este framework. Isto será demonstrado mais a frente.

NOTA: Observe que ao se usar o lindbergframework, principalmente os recursos de persistência, é necessária a dependência para o Spring. Isso não é necessário para efetuar injeção de dependências. O mecanismo de injeção do lindbergframework é independente e implementa outra solução para o problema. A dependência do Spring é requerida pois o lindbergframework usa recursos do SpringDAO.

Inversão de Controle na Prática

O mecanismo de inversão de controle do lindbergframework é simples e baseia-se inicialmente no pacote base onde o Lindberg Dependency Injection Container (LDIC - Contêiner Lindberg de Injeção de Dependência), responsável por resolver todas as dependências de cada bean, deve procurar os beans. No exemplo anteriormente mostrado o pacote org.lindbergframework.exemplo.* foi definido e isso fará com que o LDIC crie seu contexto de beans visualizando apenas beans que estão dentro do escopo do pacote org.lindbergframework.exemplo ou sub pacotes deste já que o “.*” foi definido. Abaixo vão algumas regras para a definição do pacote base:

1 – O pacote deve ser definido usando o carácter “.”;

2 – Pacotes usando o carácter “/” como por exemplo “org/lindbergframework/xxx” são inválidos;

3 – Para informar que o escopo se restrinja a um pacote único e específico e somente este basta definir o pacote sem “.*”. Por exemplo: br.empresa.beans define que apenas os beans dentro deste pacote serão visualizados. Qualquer bean dentro de um sub pacote deste não será encontrado como por exemplo um bean dentro de br.empresa.beans.exemplo não será visualizado;

4 – Para definir que o escopo é um pacote e incluir no escopo todo e qualquer bean que esteja em algum sub pacote do pacote base, como no exemplo anterior br.empresa.beans como pacote base. Para que um bean dentro de br.empresa.beans.exemplo também sejá visualizado e incluído no contexto o pacote base
deve ser definido usando ”.*” como a seguir:

br.empresa.beans.*

5 – Também é possível definir um pacote base usando seus sub pacotes mas excluindo do contexto alguns sub pacotes que não se deseje que façam parte do contexto de beans. Por exemplo, vamos levar em consideração a seguinte estrutura de pacotes:

br
br.empresa
br.empresa.beans
br.empresa.beans.exemplo
br.empresa.beans.schemas

Se fosse desejável criar um contexto de beans onde o LDIC visualizasse beans dentro do pacote br.empresa.beans e seus sub pacotes mas que o pacote br.empresa.beans.schemas não fizesse parte do contexto. Para tal, é necessário definir o pacote ou pacotes que se deseja excluir do contexto usando o caráter “:”. Para este exemplo a string do pacote básico seria da seguinte forma:

br.empresa.beans:schemas.*

O pacote definido dessa forma diz que o LDIC deve buscar beans no pacote br.empresa.beans e todos os seus sub pacotes menos o sub pacote schemas. Todo e qualquer bean que estiver dentro de br.empresa.beans.schemas os sub pacotes deste não será visualizado pelo LDIC.

Fábrica de Beans (BeanFactory)

A interface BeanFactory é fornecida pelo framework para definir as fábricas de beans que poderão trabalhar em conjunto com o LDIC. Uma classe que implementa essa interface deve fornecer instâncias de beans solicitados de acordo com um ID específico entre outras operações. Cada fábrica implementa a sua forma como cada instância de bean é obtida bem como cada dependência desses beans é resolvida e injetada no bean.

Uma outra interface importante mas que não será abordada mais a fundo neste momento e que trabalha em conjunto com as fábricas de beans é a BeanMapper. Essa interface define um mapeador de beans de modo a fornecer meta dados a uma BeanFactory para a correta criação e resolução de dependências de um bean com base em um ID específico solicitado.

A classe abstrata AbstractBeanFactory que fornece a base para fábricas de beans já contém um atributo BeanMapper de modo a fornecer um mapeador de bean para as fábricas concretas.

Injeção de Dependências

Fornecer um mecanismo para obtenção de instâncias de beans é um recurso importante. Imagine que temos uma classe chamada “A” que possui um dependência para uma classe “B” e esta última por sua vez possui uma dependência para “C”. Se solicitarmos uma instância de “A” é necessário que a instância de “A” venha preenchida com uma instância de “B” e “B” com uma instância de “C” de modo que todas as dependências diretas e indiretas de “A” estejam resolvidas e dessa forma “A” esteja pronto para ser usado.

Isso deve ser feito de forma transparente pelo mecanismo de inversão de controle de modo a fornecer recursos para diminuir o acoplamento entre as classes permitindo, por exemplo, que “A” se refira a “B” e “B” se refira a “C” através de uma interface tornando o código independente da implementação final.

Toda e qualquer interação entre “A”, “B” e “C”, poderia ocorrer através de interfaces onde o desenvolvedor não se preocupe com a implementação que em tempo de execução será utilizada. A instância do bean que contém a implementação a ser usada é responsabilidade do mecanismo de injeção de dependência que deve obter a correta instância e injetá-la onde necessário.

NOTA: Injeção de dependências não está ligado ao uso de interfaces ou não. Mesmo que não se use interfaces nem classes abstratas para prover o baico acoplamento entra as camadas o uso de inversão de controle para injeção de dependências é algo independente e importante.

O lindbergframework provê a interface DependencyManager que define um gerenciador de
dependências que tem como responsabilidade auxiliar uma BeanFactory resolvendo as dependências dos beans solicitados. A implementação padrão desta interface é um gerenciador de dependências baseado nas annotations @Bean e @Inject – AnnotationDependencyManager.

Para exemplificar considere o código abaixo que não usa a injeção automática de dependência:

public interface ISistemaFacade {
    public void cadastrarPessoa(Pessoa pessoa);
}

public class SistemaFacade implements ISistemaFacade{

    private IPessoaBC pessoaBC = new PessoaBC();

    public void cadastrarPessoa(Pessoa pessoa){
        pessoaBC.cadastrar(pessoa);
    }
}

public interface IPessoaBC {
    public void cadastrar(Pessoa pessoa);
}

public class PessoaBC implements IPessoaBC{

    private IPessoaDAO pessoaDAO = new PessoaDAO();

    public void cadastrar(Pessoa pessoa) {
        pessoaDAO.cadastrar(pessoa);
    }
}

public interface IPessoaDAO {
    public void cadastrar(Pessoa pessoa);
}

public class PessoaDAO implements IPessoaDAO{
    public void cadastrar(Pessoa pessoa){
        System.out.println("Pessoa cadastrada: "+pessoa.getNome());
    }
}

Código de teste:
Pessoa pessoa = new Pessoa("joão");
ISistemaFacade sistemaFacade = new SistemaFacade();
sistemaFacade.cadastrarPessoa(pessoa);

Observe que as classes demonstradas acima não usam recurso de inversão de controle para provimento de injeção de dependências e referem-se diretamente as implementações finais das classes ao qual dependem.

Neste caso observe que a fachada do nosso sistema depende de um BusinessController que implementa a interface IPessoaBC e a instância é criada diretamente via operador new no código tornando a fachada do nosso sistema extremamente dependente da implementação PessoaBC da interface IPessoaBC.

Da mesma forma a implementação PessoaBC dependente de uma implementação de IPessoaDAO e como foi feito na fachada a implementação PessoaDAO está diretamente referenciada no código e a instância criada diretamente no código. Neste exemplo os três níveis estão extremamente interdependentes, dificultando qualquer evolução ou manutenção no código pois o código está extremamente amarrado a implementações e não a interfaces mesmo que estejamos usando interfaces pois a implementação final é referida diretamente no código.

Qual o problema nisto? Um exemplo simples seria: Atualmente a maioria das aplicações trabalham com testes (JUnit ou algo similar). Uma pratica comum na implementação de testes é a criação de Mocks e Fakes. Que a grosso modo são objetos que simulam o real comportamento de objetos provendo para tal o comportamento desejado/esperado para um determinado teste. É comum o uso desse tipo de objetos para a criação de testes desconectados do banco. De modo que um mock seria uma implementação, por exemplo, de um DAO real só que simulando as reais operações de persistência bem como o comportamento desejado para um ou mais testes. Dito isto, no exemplo acima não seria possível normalmente (seria caso usássemos Aspecto) fornecer um Mock de IPessoaDAO para fins de testes pois o BC PessoaBC acessa diretamente a implementação real de IPessoaDAO (new PessoaDAO) e isso impossibilita a mudança da implementação do DAO a ser usada pois o BC está diretamente acoplado a implementação do DAO. Se o BC se referisse ao DAO apenas via interface e ao invés de obter a instância da implementação diretamente via operador new usasse um mecanismo de inversão de controle para injetar a implementação de IPessoaDAO desejada, poderíamos para os testes usar a implementação Mock e para aplicação real a implementação real.

Um mecanismo de inversão de controle faz todo esse trabalho deixando o desenvolvedor livre para tratar do que realmente interessa de modo que a criação e injeção dessas dependências são responsabilidades desse mecanismo, que no lindbergframework é chamado de LDIC (Lindberg Dependency Injection Container).

O lindbergframework fornece uma implementação padrão de BeanFacotry que é a classe
AnnotationBeanFactory. Essa fábrica de beans trabalha com as annotations @Bean e @Inject que são utilizadas para a definição de beans e suas dependências. Essa BeanFactory é a padrão e caso uma não seja definida o framework utilizará esta como padrão.

- @Bean: Annotation utilizada para a definir um bean. Os únicos parâmetros que ela tem é o value e singleton. O value é uma String que define o ID do bean. Esse ID deve ser único no contexto e esse ID é o que será usado para referenciar o bean. O ID é requerido nesta annotation. O parâmetro singleton é um boolean que recebe “true” quando o bean deve ser um singleton, ou seja ter apenas uma instância dentro do contexto retornando sempre a mesma instância deste e “false” caso contrário.

- @Inject: Annotation que define um ponto de injeção de dependência em um bean. O único parâmetro que esta annotation contém é o value que é o ID do bean que deve ser injetado no atributo de classe onde esta annotation foi declarada.

Abaixo é mostrado o mesmo exemplo só que fazendo uso dos recursos de inversão de controle do lindbergframework. No exemplo a seguir considere que no ponto de obtenção da instância do bean o Core do framework já foi configurado como mostrado nas sessões anteriores. Como só as implementações foram alteradas as interfaces são omitidas neste exemplo:

import org.lindbergframework.beans.di.annotation.Bean;
import org.lindbergframework.beans.di.annotation.Inject;
@Bean("sistemaFacade")
public class SistemaFacade implements ISistemaFacade{
    @Inject("pessoaBC")
    private IPessoaBC pessoaBC;

    public void cadastrarPessoa(Pessoa pessoa){
        pessoaBC.cadastrar(pessoa);
        }
}

import org.lindbergframework.beans.di.annotation.Bean;
import org.lindbergframework.beans.di.annotation.Inject;
@Bean("pessoaBC")
public class PessoaBC implements IPessoaBC{

    @Inject("pessoaDAO")
    private IPessoaDAO pessoaDAO;

    public void cadastrar(Pessoa pessoa) {
        pessoaDAO.cadastrar(pessoa);
    }
}

import org.lindbergframework.beans.di.annotation.Bean;
@Bean("pessoaDAO")
public class PessoaDAO implements IPessoaDAO{

    public void cadastrar(Pessoa pessoa){
        System.out.println("Pessoa cadastrada: "+pessoa.getNome());
    }
}

Código de teste:
Pessoa pessoa = new Pessoa("joão");
ISistemaFacade sistemaFacade = UserBeanContext.getInstance().getBean("sistemaFacade");
sistemaFacade.cadastrarPessoa(pessoa);

Observe que neste segundo exemplo as classes não referenciam como dependência nenhum implementação específica. SistemaFacade referencia apenas a interface IPessoaBC e não é afetada quanto a implementação que será usada. Da mesma forma PessoaBC referencia apenas a interface IPessoaDAO e seu funcionamento não depende e nem está acoplado a nenhuma implementação desta.

Neste último exemplo a classe SistemaFacade é anotada com a annotation @Bean onde o ID deste bean é definido como sistemaFacade. Este bean possui uma dependência com um IPessoaBC e para definir e instruir ao LDIC que faça a injeção da implementação que deve ser usada, este atributo foi anotado com a annotation @Inject definindo como parâmetro o ID do bean que deve ser injetado neste ponto. Observe que não há necessidade de definição de um setter para pessoaBC.

Da mesma forma a nossa implementação de IPessoaBC a classe PessoaBC é anotada da mesma forma, uma annotation @Bean definindo o ID desta e como temos apenas uma dependência, apenas uma annotation @Inject foi usada, neste caso para a dependência para IPessoaDAO.

Obtendo beans a partir do Contexto

Com as classes devidamente anotadas precisamos obter uma instância de nossa fachada e utilizá-la. É aí que entram as configurações feitas no core e a nossa bean factory. No trecho abaixo obtemos do CoreContext a instância da BeanFacotry e a partir desta fábrica obtemos a instância do bean da fachada do sistema e para isso passamos o ID do bean da fachada que neste caso é “sistemaFacade” para o método getBean da BeanFactory. A instância do bean da fachada retornada por este método já virá pronta com suas dependências injetadas e prontas para uso.

Para este caso a instância de sistemaFacade já virá preenchida com a instância correta de pessoaBC e este por sua vez já estará preenchido com a instância correta de pessoaDAO tudo de forma automática e transparente feita pelo LDIC.

ISistemaFacade sistemaFacade = CoreContext.getInstance().getBeanFactory().getBean("sistemaFacade");

Uma outra forma e até mais simples e direta de se obter um bean a partir do contexto usando o mecanismo de inversão e controle, é a partir da classe UserBeanContext.

Essa classe é um singleton e é um atalho para acesso da fábrica de beans padrão definida. O mesmo trecho de código apresentando anteriormente para obtenção de uma instância como exemplo de IsistemaFacade usando CoreContext poderia ser feita usando UserBeanContext da seguinte forma:

ISistemaFacade sistemaFacade = UserBeanContext.getInstance().getBean("sistemaFacade");

Observe que no trecho acima apenas a interface é referenciada. Fica a cargo do LDIC retornar a instância da implementação que deve ser usada correspondente ao ID passado.

O LDIC também efetua a injeção em dependências definidas em superclasse de modo que se PessoaBC estendesse de uma classe qualquer e esta última tivesse dependências definidas via @Inject estas dependências herdadas, mesmo private, seriam resolvidas e injetadas.

Caso o ID passado para o método getBean não corresponda a um bean válido dentro do contexto da bean factory, uma BeanNotFoundException é lançada informando que um bean com o ID especificado não foi encontrado.

O lindbergframework, já se integra com JSF e Adobe Flex e usando o framework integrado com qualquer um destes últimos não é necessário o uso de UserBeanContext.getInstance().getBean() pois no caso do JSF o managedBean já é criado e suas dependências resolvidas automáticamente pelo LDIC e no caso do Flex o bean invocado para execução de um serviço ou método remoto é resolvido pelo LDIC.

Beans com escopo Singleton

O framework também provê a possibilidade de definir um bean de modo que este seja um singleton. Isto é, tenha apenas uma instância dentro do contexto. Quando um bean é definido com o escopo singleton o LDIC manterá sempre a mesma instância e sempre que o bean for solicitado ao LDIC esta mesma instância será retornada.

Se fosse desejável, por exemplo, definir que o bean SistemaFacade deve ter uma única instância dentro do contexto, então especificaríamos seu escopo como singleton na própria annotation @Bean. Abaixo é mostrado como ficaria a classe SistemaFacade de modo a operar como um singleton.

@Bean(value = "sistemaFacade",singleton = true)
public class SistemaFacade implements IsistemaFacade{}

Observe que a annotation @Bean foi alterada adicionando o atributo singleton definindo o valor deste como true indicando que o bean SistemaFacade deve ser trabalhar como um singleton dentro do contexto. O LDIC agora retornará sempre a mesma instância de SistemaFacade quando este bean for solicitado.

quarta-feira, 25 de janeiro de 2012

Integrando com Adobe Flex via Blazeds

quinta-feira, 5 de janeiro de 2012

Integrando o contexto de Beans do lindbergframework com JSF (Java Server Faces)

Injeção de Dependência e Inversão de Controle com o lindbergframework.