A muito tempo que venho vendo que muitos desenvolvedores (muitos mesmo) que trabalham com JSF tem a necessidade de manter o estado de um managedbean (manter o bean vivo) enquanto alguma página estiver usando o mesmo (conversação) e também enquanto apenas uma mesma página estiver acessando o managedbean (escopo de view). É só da uma procurada no google que se vê milhares de posts de dúvidas.
No JSF 1 tinhamos o richfaces 3 que nos fornecia a tag <keepalive> que promovia justamente a manutenção do managedbean enquanto alguma página com um keepalive para esse managedbean estivesse acessando este bean. Com o JSF 2 o richfaces 3 não tem total compatibilidade. Uma das coisas que param de funcionar é justamente o keepalive. Então veio o richfaces 4 que da suporte ao JSF 2. Mas o detalhe é que nesta versão o keepalive foi removido pelo motivo do JSF 2 já prover o ViewScope nativo. Mas esqueceram que nós desenvolvedores usávamos também o keepalive para manter conversações entre mais de uma página que precisam acessar o mesmo managedbean e precisam manter o estado do mesmo. Resultado, uma enxurrada de dúvidas em posts pedindo socorro para resolver o problema.
Eu me deparei com o mesmo problema e fui em busca de soluções.
Este post trata sobre como fazer isto usando no JSF 2 usando o Spring 3 de uma forma fácil e transparente usando o módulo myview do lindbergframework.
Para você que usa o CDI do JEE 6 ao invés do spring, não se desespere. Para resolver o mesmo problema, existe uma extensão do CDI do myfaces chamada CODI que prover o ViewAccessScoped que nos permite manter conversações enquanto alguma página estiver usando o managedbean. Para tal veja este post tratando sobre o assunto e veja que explico como usar o CODI tanto com o maven quanto em projetos não maven.
Vamos ao que interessa.
Eu pesquisei, pesquisei, quebrei a cabeça e estudei como fazer para colocar o escopo de view e de conversação em managedbean´s gerenciados pelo spring integrado com o jsf.
Então criei um módulo do lindbergframework que é independente do resto do framework e trará de agora em diante várias utilidades para a camada de visão. A release 1.0 que é que estou abordando neste post prover como recurso justamente todo a infraestrutura e configuração mais complicada e pesada para colocar estes escopos para funcionar.
Então vamos ao que interessa.
Para usar o myview e colocar os escopos para funcionar é muito simples.
Basta colocar o myview em seu projeto a partir do maven ou baixando diretamente o zip com o jar do myview e suas dependencias incluindo spring (se seu projeto ja possui as libs do spring as mesmas que estão dentro do zip do myview não são necessárias e devem ser ignoradas) e seguir alguns passos simples que serão descritos abaixo.
Para obter o myview pelo maven basta colocar o repositório abaixo, caso seu pom.xml ainda não tenha o mesmo declarado:
<repository>
<id>sonatype-releases</id>
<name>Sonatype Releases Repository</name>
<url>http://oss.sonatype.org/content/repositories/releases/</url>
</repository>
E adicionar a dependência para o myview como abaixo:
<dependency>
<groupId>org.lindbergframework.web</groupId>
<artifactId>lindbergframework-myview</artifactId>
<version>1.0</version>
</dependency>
Para baixar diretamente o ZIP contendo o myview + spring + dependencias clique no link abaixo:
https://lindbergframework.googlecode.com/files/lindbergframework-myview-1.0.rar
NOTA: Essa pasta zip com os jars necessários para se utilizar o myview com o spring 3 e o jsf 2 contém os jars do lindbergframework-myview e suas dependencias. E inclui também so jars do spring caso não tenha adicionado ainda. Como provavelmente sua aplicação já tem os jars do spring fique a vontade para desconsiderar os do spring. Mas fique atento que todos são necessários, incluindo o do myfaces-orchestra-core20-1.4, e mesmo que sua aplicação ja tenha o spring pode ser que falte algum jar do spring que é requerido pelo myview como por exemplo spring-orm, spring-tx, spring-web, etc... Então é bom ficar atento.
Depois do myview obtido e devidamente instalado em sua aplicação que usar JSF 2 + spring 3 siga as instruções abaixo.
VAMOS CONFIGURAR O MYVIEW DE FORMA SIMPLES EM ALGUNS PASSOS
- Adicione no seu xml arquivo de configuração do spring (applicationContext.xml) a importação para o xml do myview
<import resource="classpath:/META-INF/myview-spring-init.xml"/>
- Se estiver usando algum framework orm como hibernate ou jpa lembre sempre daaqueles probelmas de Lazy Initialization são uma constante para quem não sabe trabalhar adequadamente com esse tipo de mecanismo com JSF usando escopos de conversação e view. Para resolver isso, basta declarar o bean com id persistentContextFactory no seu applicationContext.xml adequado para qual tecnologia vai usar, hibernate ou jpa, passando para ele respectivamente a sessionFactory ou entityManager de acordo com o que tiver usando como abaixo:
- Se estiver usando Hibernate declare
<bean id="persistentContextFactory"
class="org.lindbergframework.web.conversation.spring.HibernatePersistenceContextFactory">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
IMPORTANTE: Lembrando que ref="sessionFactory" espera que sua sessionFactory tenha o ID 'sessionFactory'. Caso o ID da sua sessionFactory seja outro você deve mudar o valor desse atributo também.
- Se estiver usando JPA declare da seguinte forma
<bean id="persistentContextFactory"
class="org.apache.myfaces.orchestra.conversation.spring.JpaPersistenceContextFactory">
<property name="entityManagerFactory" ref="entityManagerFactory"/>
</bean>
IMPORTANTE: Definir esse bean "persistentContextFactory" no seu applicationContext.xml não é requerido para o funcionamento dos escopos adicionais do myview. Isto torna-se importante pelo fato de que usando hibernate e jpa nos escopos persistentes além de request como view e conversação (access) é necessário uma manipulação diferente da session do hibernate e do entityManager da JPA de modo a evitar problemas comums como o corriqueiro problema de lazy initialization entre outros. Então se você usa hibernate ou jpa é expressamente recomendado que declare essas 3 meras linhas de XML em seu applicationContext.xml afim de evitar dores de cabela e problemas.
Da mesma forma que a sessionFactory, se sua entityManagerFactory tiver um ID diferente você deve mudar o valor do atributo "ref" passando o correto ID da sua "entityManagerFactory".
TA QUASE PRONTO
- Agora é necessário que você no seu faces-config.xml, caso não tenha declarado ainda, declare o seguinte:
<application>
<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
</application>
- Agora no seu web.xml é necessário que declare os listeners do spring caso ainda tenha configurado (se sua aplicação ja usa spring, isso certamente ja deve ta congiruado e funcionando. Coloquei apenas para lembrar)
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
- Continuandono seu web.xml, para funcionar o escopo de conversação, é requerido que você declare:
<listener>
<listener-class>org.apache.myfaces.orchestra.conversation.servlet.ConversationManagerSessionListener</listener-class>
</listener>
- Caso esteja usando hibernate é bom você declarar o filtro que vai lhe garantir o recurso de OpenSessionInView nos novos escopos adicionados pelo MyView. Isso é necessário para evitar os problemas referentes a "session is closed" e de lazy initialization nas páginas JSF.
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>org.lindbergframework.orm.hibernate.support.MyViewScopesOpenSessionInViewFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
PRONTO TA TUDO CONFIGURADO.
Agora é só usar os escopos anotando seus managedBeans com as seguintes anotações de acordo com a necessidade:
* @AccessScoped : Mantem o managedBean "vivo" enquanto alguma página estiver usando o mesmo. Ou seja enquanto o mesmo estiver participando da conversação da página corrente. Quando uma página que não usa o managedBean for acessada o mesmo será destruído e seu estado perdido. Quando uma página que usa o mesmo for novamente acessada, uma nova instancia do managedBean será criada e usada enquanto houver uma página usando o mesmo.
Exemplo:
@Component
@AccessScoped
public class EscopoConversacaoMB{
//
}
* @SameViewScoped : Mantem o managedBean "vivo" enquanto a mesma página estiver ativa. Quando o usuário for para qualquer outra página diferente o managedBean é destruído e seu estado perdido. Quando o usuário acessar novamente uma página que usa o managedBean, uma nova instancia é criada e continuará "viva" enquanto o usuário permanecer na mesma página.
Exemplo:
@Component
@SameViewScoped
public class EscopoMesmaPaginaMB{
//
}
IMPORTANTE: Para que o escopo seja aplicado, é necessário que seu managedbean seja um bean do spring. Ou seja é necessário que caso você esteja usando definição de beans via annotation, você defina seus managedBeans com @Component ou caso esteja usando definições de beans via XML, declare os mesmos em seu applicationContext.mxl
Pronto, é isso.
Mais uma vez, abaixo o link para download:
https://lindbergframework.googlecode.com/files/lindbergframework-myview-1.0.rar
Bugs, opiniões, solicitações, críticas, dúvidas de como colocar pra funcionar, eventuais problemas, enfim, para contato enviar email para os endereços abaixo:
lindbergframework@lindbergframework.org
victorlindberg713@gmail.com
Aproveitando a oportunidade, para uma solução simples, plugável e flexivel para eliminar sql dos seus DAOs de projetos que não usam frameworks ORM e sim JDBC ou springDAO puro e direto, para uma solução simples de acesso, população e abstração de acesso a stored procedures e stored functions, usando ou não cursores, população de objetos complexos descomplicada e automática a partir de queries sem a necessidade de se preocupar em trabalhar com ResultSet´s, de percorrer ResultSet´s criando e populando seus objetos, veja o lindbergframework em https://code.google.com/p/lindbergframework/ ou leia diretamente a documentação em https://lindbergframework.googlecode.com/files/lindbergframework-1.0-doc.pdf.
Este blog se destina a posts, comentários, passo a passo, tutoriais rápidos, curtos e focados, abordando funcionalidades, soluções, exemplos de uso, enfim, uma fonte de informações direcionada sobre o lindbergframework. Este blog não se destina a aprofundar e nem demonstrar de forma abrangente nenhum assunto abordado sobre o framework. Para documentação completa e suporte sobre o framework favor acessar o site oficial http://www.lindbergframework.org
terça-feira, 28 de fevereiro de 2012
quarta-feira, 25 de janeiro de 2012
Integrando com Adobe Flex via Blazeds
Da mesma forma como foi apresentada no post referente a a integração com JSF (link), é possível integrar o contexto de beans com o Adobe Flex a partir do BlazeDS. Para tal, basta declarar a implementação de flex.messaging.FlexFactory do lindbergframework, que promove a integração, no arquivo servicesconfig.xm como a seguir. A partir daí os beans contidos no contexto estão acessíveis de forma transparente para a camada de visão/front-end Flex. Da mesma forma como foi apresentada a integração do contexto com o JSF, os beans são acessados via seus respectivos ID´s.
<?xml version="1.0" encoding="UTF-8"?>
<services-config>
<factories>
<factory id="lindbergFactory" class="org.lindbergframework.integration.web.flex.LindbergFlexBeanFactory" />
</factories>
</services-config>
<?xml version="1.0" encoding="UTF-8"?>
<services-config>
<factories>
<factory id="lindbergFactory" class="org.lindbergframework.integration.web.flex.LindbergFlexBeanFactory" />
</factories>
</services-config>
quinta-feira, 5 de janeiro de 2012
Integrando o contexto de Beans do lindbergframework com JSF (Java Server Faces)
A integração do JSF com o contexto de Beans do lindbergframework possibilita o uso de qualquer Bean declarado com annotation @Bean e que faça parte do contexto nas páginas JSF, diretamente via o ID do Bean.
Exemplo: Considere que temos um managedBean chamado ManterPessoaMB cujo ID do mesmo, declarado via annotation @Bean seja manterPessoaMB.
@Bean("manterPessoaMB")
public class ManterPessoaMB {
public String cadastrar(){
//... implementação da ação de cadastrar
return null;
}
}
ATENÇÃO: Para que o bean acima faça parte do contexto de beans o mesmo deve estar direta ou indiretamente abaixo do pacote base, definido na configuração de CORE.
Para efetuar a integração e possibilitar que usemos o bean manterPessoaMB diretamente em páginas JSF a partir do seu ID, é necessário declarar apenas o ELResolver do lindbergframework, org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver no faces-config.xml da aplicação como abaixo:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">
<application>
<el-resolver>org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver</el-resolver>
</application>
</faces-config>
Basta isso para que o contexto de beans do lindbergframework esteja acessível nas páginas JSF.
Abaixo é mostrado um exemplo de um botão que acessa o bean ManterPessoaMB a partir do seu ID definido via annotation @Bean, manterPessoaMB, e chama o action 'cadastrar' declarado no mesmo.
<h:commandButton action="#{manterPessoaMB.cadastrar}" value="Cadastrar" />
Exemplo: Considere que temos um managedBean chamado ManterPessoaMB cujo ID do mesmo, declarado via annotation @Bean seja manterPessoaMB.
@Bean("manterPessoaMB")
public class ManterPessoaMB {
public String cadastrar(){
//... implementação da ação de cadastrar
return null;
}
}
ATENÇÃO: Para que o bean acima faça parte do contexto de beans o mesmo deve estar direta ou indiretamente abaixo do pacote base, definido na configuração de CORE.
Para efetuar a integração e possibilitar que usemos o bean manterPessoaMB diretamente em páginas JSF a partir do seu ID, é necessário declarar apenas o ELResolver do lindbergframework, org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver no faces-config.xml da aplicação como abaixo:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd" version="2.0">
<application>
<el-resolver>org.lindbergframework.integration.web.jsf.beans.LindbergBeanJsfResolver</el-resolver>
</application>
</faces-config>
Basta isso para que o contexto de beans do lindbergframework esteja acessível nas páginas JSF.
Abaixo é mostrado um exemplo de um botão que acessa o bean ManterPessoaMB a partir do seu ID definido via annotation @Bean, manterPessoaMB, e chama o action 'cadastrar' declarado no mesmo.
<h:commandButton action="#{manterPessoaMB.cadastrar}" value="Cadastrar" />
Injeção de Dependência e Inversão de Controle com o lindbergframework.
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.
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.
Assinar:
Postagens (Atom)