Principais padrões J2EE para a construção de aplicações não distribuídas – Parte II

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (8)  (2)

Não perca a continuação deste tutorial sobre padrões, estratégias de projeto e Struts.

 

View Helper

Um dos principais objetivos que desejamos alcançar no desenvolvimento de nossas aplicações é a clara divisão de responsabilidades. No modelo MVC vimos que a camada de visão (view) é responsável pela apresentação dos dados. Quando lógica de negócio e lógica para formatação dos dados estão inseridas nesta camada, o sistema torna-se menos flexível, reutilizável e suscetível à mudanças. Isto também prejudica a clara separação do trabalho de web designers e programadores.

 

Como vimos, todo o processamento da lógica de negócio deve estar centralizado na camada modelo do MVC. Isto implica que não haverá scriptlets com regras de negócio em nenhuma parte das páginas JSP, que irão somente apresentar o estado do modelo que chega encapsulado em helpers denominados value objects (que nada mais são do que Java Beans que representam uma porção dos dados do modelo num dado instante). Procedendo desta forma, estaremos prezando pelo reaproveitamento de código e manutenibilidade, já que porções de códigos que fazem a mesma coisa foram retirados dos scriptlets e inseridos em classes Java que fazem parte do modelo.

 

Devemos evitar também a inclusão de código para formatação dos dados nas páginas JSP, tais como código para controle de fluxo ou iteração. Nesses casos a melhor opção é utilizar custom tag helpers, que encapsulam estas funcionalidades que, de outra forma, seriam embutidas diretamente no JSP como scripts, reduzindo a modularidade e manutenibilidade. Veja abaixo o trecho de código que mostra a apresentação de dados de um empregado feita com e sem custom tags:

 

cod1padroes1.JPG 

cod2padroes.JPG

 

Agora a versão usando custom tag:

 

cod3padroes.JPG

 

A framework struts disponibiliza uma vasta biblioteca de tags que desempenham inúmeras funções que facilitam a inclusão de lógica de formatação em páginas JSP.

 

Value Object

Os dados que vêm do modelo são expostos à camada de visão através de DTOs (Data Transfer Objects) que podem ser Value Objects. Um value object é um objeto Java arbitrário que encapsula os valores de retorno dos componentes de negócio, como por exemplo o retorno de um método de um DAO. Geralmente seus atributos são feitos públicos e o construtor recebe cada um de seus valores. O nome das classes Java que representam value objects podem receber um “VO” para identificar que participam deste padrão.

 

Data Access Object

A maioria das aplicações J2EE necessitam, num dado momento, acessar algum tipo de informação persistente. Estas informações podem estar nos mais diversos dispositivos de armazenamento, como

servidores mainframes, repositórios LDAP (Lightweight Directory Access Protocol), banco de dados relacionais e orientado a objetos, ou mesmo dados provenientes de serviços disponibilizados por sistemas externos, como quando há integração business-to-business (B2B).

 

Estes dispositivos são acessados por diferentes APIs, muitas vezes proprietárias e específicas. Por exemplo, um banco de dados relacional pode ser acessado pela API JDBC. Esta API possibilita às aplicações emitir comandos SQL que são a maneira padrão para interação com as tabelas contidas nestes bancos. Ainda assim, mesmo que estejamos considerando apenas o ambiente de sistemas gerenciadores de banco de dados relacionais (SGBD), a sintaxe dos comandos SQL pode variar dependendo do SGBD em particular.

 

Esta diversidade de fontes de dados pode criar uma dependência da aplicação em relação ao código de acesso aos dados, uma vez que os componentes de negócio conterão código específico das APIs e dispositivos de armazenamento sendo utilizados. Isto introduz um alto acoplamento entre a lógica de negócio e a implementação do acesso às fontes de dados, tornando mais difícil migrar a aplicação de uma fonte de dados para outra.

 

A solução é abstrair e encapsular o acesso a fontes de dados através de Data Access Object (DAO). Um DAO implementa o mecanismo de acesso para se trabalhar com uma fonte de dados específica. Um componente de negócio fica exposto apenas à interface do DAO, que esconde toda a complexidade relativa à interação com a fonte de dados sendo utilizada. Como a interface de um DAO não se altera quando sua implementação precisa ser modificada, este padrão permite alterar a fonte de dados sendo utilizada numa aplicação sem afetar os componentes de negócios que fazem uso deste.

 

Quando utilizamos DAO é comum utilizarmos também o padrão Abstract Factory. Uma fábrica de objetos tem a função de criar objetos de um determinado tipo e, quando uma existe, devemos utilizá-la para criar determinados objetos ao invés de fazê-lo explicitamente através do comando new. Pense no seguinte, uma vez que nossa aplicação está cheia de DAOs, cada um com os métodos apropriados para acessar uma determinada fonte de dados, como fazer para substituir um DAO por outro quando a fonte de dados precisar ser alterada? Bom, uma alternativa é remover todas as classes que representam DAOs na aplicação e substituí-las por classes com o mesmo nome (e é claro mesma interface) porém projetadas para acessar a nova fonte de dados. Uma opção mais profissional e flexível é criar uma classe abstrata que representa uma fábrica de DAOs. Nesta classe estarão definidos os métodos para criação de todos os DAOs que a aplicação precisa. Quando o dispositivo de armazenamento persistente é passível de mudança, deve-se criar uma fábrica concreta de DAOs, derivada da classe abstrata, específica para cada fonte de dados a ser utilizada. Assim, é possível, por exemplo, definir uma variável global na aplicação do tipo DAOFactory e inicializá-la com a fábrica concreta necessária num dado momento. Quando a fonte de dados precisar ser alterada, basta inicializarmos a variável com outra fábrica capaz de construir DAOs aptos a interagir com a nova fonte. Em qualquer parte da aplicação onde um DAO está sendo criado, e isto certamente está sendo feito utilizando-se a variável global com a fábrica de DAOs corrente, nada precisará ser modificado. A figura 2.1 apresenta o diagrama de classes deste esquema.

 

fig21padroes.JPG 

Figura 2.1: Abstract Factory para Data Access Object.

 

Business Delegate

A camada cliente pode interagir diretamente com os serviços disponibilizados pela camada responsável por implementar a lógica do negócio. Esta interação direta expõe sobremaneira a API destes serviços de negócio, tornando a camada de apresentação mais vulnerável às mudanças efetuadas nos métodos de negócio. Dito isso, pode-se concluir que é desejável reduzir o acoplamento entre estas duas camadas, escondendo ao máximo detalhes de implementação.

 

O padrão para resolver este problema é o business delegate que age como uma abstração, no lado cliente, para os métodos de negócio. Um business delegate pode esconder, por exemplo, a complexidade da busca por recursos como EJBs, numa aplicação distribuída, ou data sources, que possibilitam obter conexões a fontes de dados. Sua utilização torna transparente aos usuários dos serviços de negócio detalhes sobre serviços de nome e diretório e a busca nestas estruturas. Outro benefício é o tratamento das exceções que podem ser lançadas pelos serviços de negócio, o qual pode ser efetuado antes que uma delas chegue à camada de apresentação. Assim, caso realmente o problema ocorrido não seja recuperável, uma mensagem mais amigável pode ser produzida e apresentada ao usuário.

 

Para ler a primeira parte deste tutorial, acesse:

http://www.devmedia.com.br/visualizacomponente.aspx?comp=1812&site=6

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?