Criando aplicações Web com EJB e padrões de projeto

Assim que um programador ganha experiência na linguagem Java, começa a se deparar com situações comuns em vários tipos de projetos que demandam algum tipo de solução padronizada. Na cabeça do desenvolvedor, deve surgir um pensamento semelhante a este: “essas situações ou problemas, que provavelmente já foram enfrentadas por outros desenvolvedores anteriormente, devem possuir uma forma ideal de serem solucionadas ou implementadas”. E muitas destas formas realmente existem: são os chamados “padrões de projeto” (design patterns).

O importantíssimo livro Design Patterns: Elements of Reusable Object-Oriented Software (com o título nacional “Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos”), de autoria da chamada “Gang of Four” (“Turma dos Quatro”: Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides), foi o grande responsável por popularizar o termo “padrão de projeto” em software, como uma espécie de “receita básica” para a solução de problemas comuns em projetos orientados a objetos.

Publicado em 1994, o livro traz uma série de situações e problemas comuns em softwares orientados a objetos e as respectivas “soluções ideais”, as quais foram denominadas de “padrões de projeto”. Apesar dos exemplos do livro estarem originalmente em C++ e Smalltalk, podem (e devem) ser aplicados a qualquer linguagem de programação orientada a objetos. Obviamente, estes também possuem implementação em Java.

No livro, os padrões de projeto são divididos em três categorias:

• Padrões Criacionais (creational patterns): usados para criação de objetos seguindo alguma regra, sem que estes precisem ser instanciados diretamente. É dentro desta categoria que ficam, por exemplo, dois padrões que são “velhos conhecidos” dos desenvolvedores: o Singleton, que estabelece uma única instância compartilhada para um objeto, e o Factory Method, onde um método é usado para retornar uma nova instância de uma classe;
• Padrões Estruturais (structural patterns): servem para definir a estrutura e composição dos objetos e classes. O padrão de projeto Façade, amplamente usado em aplicações Web com Enterprise JavaBeans, faz parte desta categoria;
• Padrões Comportamentais (behavioral patterns): são aqueles que estabelecem padrões de comportamento e funcionamento dos objetos, mais especificamente a maneira como estes se comunicam. Dentro desta categoria está o padrão Observer, que estabelece um objeto “observador” que deverá ser notificado no caso de uma mudança de estado em algum outro objeto.

É muito provável que você, mesmo sem saber sobre o conceito de padrões de projeto, já tenha se deparado com alguns deles em programas Java. O padrão criacional Factory Method, por exemplo, é usado em diversas classes da linguagem para retornar uma nova instância de um objeto, assim como o Singleton, que traz uma instância única compartilhada.

Outro padrão de projeto muito utilizado é o conhecido MVC (Modelo-Visão-Controle). Este padrão foi estabelecido em 1979 por Trygve Reenskaug, para uso com a linguagem Smalltalk.

O MVC define três divisões (ou camadas) básicas para um aplicativo:

• Modelo: consiste nos dados e na lógica existente na operação destes;
• Visão: é a interface do aplicativo, aquilo que efetivamente será apresentado ao usuário;
• Controle: tem o papel de fazer a “ponte de comunicação” entre o modelo e a visão.

A ideia central por trás do MVC é desacoplar o máximo possível o Modelo da Visão, de forma que sejam independentes. Dessa maneira, os elementos pertencentes a estas duas categorias terão sua possibilidade de reutilização maximizada.

Veja no diagrama da Figura 1 um exemplo de como deve ser a comunicação entre os elementos de um sistema implementado com MVC.

O MVC é considerado como um padrão do tipo estrutural e, apesar de ser citado no livro Design Patterns, não é incluído como um dos “padrões de projeto” efetivos desta obra. Ao invés disso, Gamma, Helm, Johnson e Vlissides “decompõem” o MVC em três outros padrões definidos no livro: o Observer, o Composite e o Strategy.

As vantagens de reutilização proporcionadas pela divisão de uma aplicação nestes três “campos” do MVC são bastante óbvias. A interface de uma aplicação, a Visão do MVC, é geralmente “amarrada” a uma plataforma específica, e sua portabilidade é bastante limitada. Já as classes que definem o Modelo, desacopladas de uma interface específica, podem ser intercambiadas e reutilizadas em diversos projetos.

Padrões de projeto no Java EE

A especificação do Java EE 6 define, entre outras tecnologias, os EJBs (Enterprise JavaBeans) para a definição das regras de negócio e o framework JSF (JavaServer Faces) para a camada de visualização de uma aplicação Web. A Oracle disponibiliza, inclusive, uma lista de padrões de projetos que podem ser aplicados especificamente em aplicações Java EE (link disponível no final do artigo).

Podemos considerar os EJBs como classes Java “turbinadas” que, por meio do uso de annotations específicas, têm acesso a recursos avançados como persistência de dados em um modelo objeto-relacional (por meio da JPA – Java Persistence API), controle de transações, envio e recebimento de mensagens e injeção de contexto e dependência. Veja a Nota 1. Com o uso de um servidor de aplicações compatível com as especificações do Java EE 6 (como o GlassFish), uma aplicação Web Java pode ser construída se beneficiando desses diversos recursos.