>>Construindo uma camada de negócios reutilizável e flexível
Aprenda a criar na prática uma infra-estrutura para camada de negócios para obter produtividade sem comprometer a flexibilidade.

A criação de frameworks e classes de infra-estrutura que melhoram a produtividade, muitas vezes amarram a solução da aplicação, não deixando espaço para funcionalidades que possuam um comportamento não usual. Com isso, acaba-se precisando sair da arquitetura prevista e implementando funcionalidades fora da filosofia de toda a aplicação. Neste artigo, será visto na prática como se pode aliar produtividade e flexibilidade, criando uma solução para camada de negócios que funcione em 90% dos casos, mas deixando uma brecha para que seja possível a extensão para os outros 10%. Também será mostrado como essa flexibilidade pode permitir a adaptação da arquitetura sem afetar as regras de negócio.

Em uma daquelas “conversas de cafezinho” em que os desenvolvedores costumam falar mal do cliente, dos analistas e das aplicações em que estão trabalhando, um amigo meu com um “certo ar de revolta” disse: “Nesse sistema, as mesmas coisas são feitas de forma diferente. Isso não está certo! A implementação deveria ser feita de forma padronizada.” Nessa frase que, a princípio pareceu ser de senso comum, me fez perceber algo que até então eu ainda não havia percebido: as mesmas coisas não devem ser implementadas de uma forma padrão, se elas são parecidas devem ser implementadas uma única vez! Ao expor essa idéia na conversa, todos pareceram concordar, mas ficaram com “uma interrogação na cabeça”: como fazer isso?

A partir desse dia, tive a oportunidade de desenvolver melhor essas idéias e aplicá-las em diversos projetos. A prática mostrou que uma boa infra-estrutura arquitetural melhora bastante a produção da equipe e pode ser reaproveitada inclusive entre projetos de natureza diferente. Como exemplo, pode ser citado que a mesma infra-estrutura foi utilizada em uma aplicação desktop que acessa um servidor de aplicações e em uma aplicação web que acessa a base de dados diretamente. Como resultado desse trabalho, obteve-se um aumento na produtividade da equipe, que deixou de perder seu tempo com códigos repetitivos, para poder concentrar seus esforços nas regras de negócio específicas da aplicação. O que será mostrado neste artigo são os fundamentos e as principais idéias de como conseguir melhorar a produtividade da equipe, sem que isso afete a flexibilidade, deixando espaço para aqueles casos em que as regras são completamente diferentes. Inicialmente, serão abordadas questões relativas à construção da interface de persistência, passando em seguida para as regras de negócio. As camadas de controle e interface com o usuário não serão abordadas, porém espera-se que, com os conceitos apresentados, as mesmas idéias também possam ser aplicadas na construção dessas camadas.

Criando uma infra-estrutura de persistência

A lógica de persistência é normalmente um código bastante repetitivo de ser feito. Existem diversos frameworks como o Hibernate, o iBatis e até mesmo o DbUtils da Jackarta Commons que reduzem a quantidade de código necessária para persistir e recuperar objetos na base de dados. Independentemente da tecnologia utilizada para o acesso aos dados, existe sempre dois tipos de classes envolvidas nesse processo: um que representa a entidade persistente e outra que encapsula as operações realizadas na base de dados.

A entidade persistente normalmente é representada por uma Java Bean, ou seja, de uma forma simplificada uma classe com diversos métodos getters e setters representando cada propriedade que ela possui. As instâncias desse tipo de classe trafegam entre as camadas da aplicação representando entidades relacionadas diretamente com o negócio da aplicação. Como as informações desses objetos são muito dependentes das regras de negócio, não existe uma forma muito eficiente de generalizar esse tipo de classe. Na verdade, é nesse tipo de classe que vale a pena investir esforço de desenvolvimento e modelagem, pois ele está relacionado com os requisitos do sistema.

O tipo de classe que encapsula as operações com a base de dados também é conhecida como DAO (Data Access Object). Essa classe tem a função de isolar do resto da aplicação a forma como o sistema interage com um banco de dados. Normalmente, o código dos DAOs é bastante repetitivo e não muito relacionado com a regra de negócios. Por exemplo, a inserção de objetos de classes diferentes normalmente gera um código bem parecido, diferenciando apenas pela forma na qual aquele tipo de objeto é traduzido para o paradigma relacional do banco de dados. As operações dos DAOs também são bem parecidas como inserção, atualização, recuperação e exclusão.

No caso dos DAOs, como o código gerado é bem parecido e as operações são as mesmas, porque não generalizar o máximo possível? Pessoalmente, já pude presenciar diversas implementações que tratavam DAOs com operações equivalentes de forma diferente, sendo que cada um implementava uma interface diferente, conforme ilustrado na figura 1. A desvantagem dessa abordagem é que os DAOs não podem se beneficiar do polimorfismo, ou seja, não podem ser tratados como se fossem do mesmo tipo. Quando formos ver detalhes sobre a construção da camada de negócios, que usa diretamente os DAOs, vai ficar mais claro como isso pode ser essencial para a diminuição do número de classes total do sistema. Na figura 2 temos um diagrama de classes mostrando como poderia ser utilizada uma única interface para vários DAOs. A desvantagem dessa abordagem é que as assinaturas dos métodos utilizam Object e não a classe realmente persistida pelo DAO. Essa desvantagem pode ser facilmente contornada com a utilização de tipos genéricos. A Listagem 1 mostra como poderia ser construída uma interface considerando tipos genéricos para o objeto persistido e seu identificador, e a Listagem 2 mostra um exemplo de como um DAO poderia implementar essa interface.

Figura 1. Diagrama de classes em que os DAOs implementam interfaces diferentes, porém com operações parecidas.

Figura 2. Diagrama de classes em que DAOs diferentes implementam a mesma interface, podendo ser tratados da mesma forma pela aplicação.

>>Adobe Flex 2
Crie aplicações para a Web com interface rica, amigável e integrada a aplicações Java existentes

A Web, criada originalmente com o propósito de ser uma plataforma para exibição de documentos utilizando o hypertexto, evoluiu e hoje é também uma plataforma para aplicativos e negócios. Conheça como a tecnologia Adobe Flex funciona e como construir sistemas que atendam a estas novas demandas.

Em 2001, a Macromedia (agora Adobe) usou pela primeira vez o termo Rich Internet Applications (RIA) para descrever um novo modelo de aplicativos para a Web, conforme figura 1, baseado no que aplicativos tradicionais para desktop ofereciam (interface responsiva e intuitiva) com o melhor da Internet (seu alcance global e comunicação) criou uma plataforma para o desenvolvimento de RIAs, visando aprimorar a camada de apresentação das aplicações. Conhecida como Flash Platform, esta se baseia no já conhecido padrão Flash e em um cliente já muito difundido, com penetração superior a 98% dos computadores conectados à Internet, o Flash Player, um cliente único e disponível em múltiplas plataformas, inclusive em dispositivos móveis e celulares, sob o nome de Flash Lite. Fazendo uma analogia, o conceito do Flash Player se assemelha muito ao conceito da JVM.

A Flash Platform oferece uma comunicação com o servidor, mais efetiva para as atividades desenvolvidas pelos usuários nos aplicativos, pois está em sua natureza uma comunicação assíncrona: o usuário pode continuar a realizar a sua tarefa enquanto os dados são obtidos do servidor, sem a necessidade de atualizar toda a aplicação, como ocorre em aplicações tradicionais feitas com HTML, ao utilizar a metáfora de páginas para representar estágios da aplicação. Esta plataforma oferece ainda toda a capacidade gráfica e interatividade em controles para o usuário, inerentes da plataforma. Contudo, o ambiente de desenvolvimento Flash Professional não oferecia um modelo de programação coerente, nos moldes que os desenvolvedores já estavam acostumados. O Adobe Flex oferece um modelo de programação mais coerente aos desenvolvedores de aplicativos, com o mesmo intuito de utilizar Flash Platform para a camada de apresentação dos sistemas.

Figura 1. As Rich Internet Application aproveitam o melhor de dois mundos.

O que é o Adobe Flex

Visando oferecer um modelo de programação mais versátil e robusto para o desenvolvimento de aplicativos, o Flex foi concebido. O Adobe Flex é uma solução completa para criar e fornecer aplicações ricas, robustas, interativas e que possibilitem uma interface mais amigável e intuitiva para o usuário. A linha de produtos (figura 2) é composta por:

• Flex SDK 2: gratuito, é a biblioteca principal de componentes, linguagem de desenvolvimento e o compilador;
• Flex Charting: componentes de gráficos, customizáveis e extensíveis (não é gratuito);
• Flex Data Services 2: uma aplicação J2EE que possibilita transferências de dados de alta performance, sincronização de dados entre diferentes camadas da aplicação, resolução de conflitos de dados, mensageria em tempo real e integração nativa com Hibernate (possui uma versão gratuita com limitações de uso, mas também possui uma versão paga);
• Flex Builder 2: ambiente de desenvolvimento na forma de plugin para o Eclipse que oferece editor de código, debugger integrado e ferramentas visuais para construção de tela (não é gratuito).

Figura 2. Produtos da linha Flex 2.

No Flex, utilizam-se duas linguagens de programação. A primeira, conhecida como MXML, é uma linguagem de marcação – similar ao HTML – mas baseada em uma notação declarativa em XML, é utilizada para descrever elementos da interface e expor as funcionalidades da aplicação. A segunda, o ActionScript 3.0, é uma implementação do ECMAScript, fortemente orientada a objetos e utilizada para escrever lógicas de negócio no cliente.

Estas duas linguagens expõem e manipulam tanto a biblioteca de componentes do Flex quanto as APIs disponíveis, como, por exemplo, as APIs de desenho, manipulação de gráficos, comunicação, multimídia, entre outras. Igualmente, utilizando-se estes recursos permite facilmente a criação de componentes customizados.

O desenvolvimento da aplicação pode ser feito com qualquer editor de texto, ou ainda com o Flex Builder 2, que oferece recursos completos de uma IDE. Uma vez escrita a aplicação, esta é compilada (utilizando o Flex SDK 2 ou diretamente no Flex Builder) gerando o bytecode em um arquivo binário, de extensão SWF. Este arquivo é o cliente de uma aplicação em Flex e seu deploy pode ser feito em um servidor Web tradicional, simplesmente copiando o arquivo, tal como com páginas HTML.

Leia o artigo completo na revista MUNDOJAVA, já nas bancas!