Camadas em aplicações Java EE

1. Introdução

Todos os dias, como programadores, desenvolvemos aplicativos dos mais diversos tipos e finalidades. Estes aplicativos vão tomando forma à medida que novos requisitos são acrescentados ao sistema, de forma a compor todo um emaranhado de código finito, bem disposto e organizado que, no final, resultará no produto desejado.

Mas basta ter uma pequena experiência no mundo de desenvolvimento corporativo para saber que isso nem sempre se dá de maneira tão bonita quanto descrita acima. Inúmeros processos são seguidos, regras, reuniões, coletas são feitas para que o produto saia como desejado... e, quando se trata de codificação, nós seguimos os "padrões". Padrões são conceitos pensados e desenvolvidos de forma a manter um nível de organização mínimo entre projetos afins ou que usem tecnologias afins. Isso torna a experiência de desenvolver software "mais tranquila", uma vez que muitos outros já passaram por situações iguais ou semelhantes, e deu certo!

Mas, ainda fica a lacuna: "Por que mesmo diante de tantas experiências passadas aos outros através dos padrões, ainda é tão difícil e arriscado escrever softwares?". Bem, acredito que inúmeros fatores estejam envolvidos, mas um dos principais deles é o fato de que as regras estão ficando cada vez mais complexas e complicadas. E quando temos regras mais complexas, padrões mais sofisticados devem ser bem pensados.

Para nós, os aprendizes dos padrões, cabe a tarefa de aprendê-los mais rapidamente, e de forma mais concisa, coesa. Neste artigo, falaremos sobre os padrões de camadas usadas na grande maioria das aplicações web, além de tratarmos mais a fundo sobre assuntos como MVC, apps 3-tier, dentre outros assuntos inerentes ao todo.

2. Arquitetura de camadas JEE

A Figura 1 descreve sucintamente como a maioria das aplicações web se comportam, no que se refere à sua organização em camadas. Essa divisão geralmente se caracteriza por ter quatro camadas bem definidas: Cliente, Web, Negócio e Persistência. Mas requisito a pergunta: Será que sabemos mesmo o que cada uma faz? Sabemos quando usá-las, como usá-las? Sabemos o que pode ser feita em cada uma, ou se devemos ou não retirar alguma? Essas dúvidas são sempre comuns, principalmente quando não temos tanta experiência na tecnologia/modelo referido.

Falemos sobre elas então.

2.1. Cliente

É a primeira camada da aplicação, aquela que geralmente representa algum recurso gráfico de acesso feito pelo usuário. Nessa camada estão localizados elementos como browsers, outra aplicações, sistemas JSE, celulares, GPS, dentre outros.

De fato, não há tanto a falar sobre essa camada, uma vez que ele praticamente não representa nenhum esforço programático. Vale lembrar que linguagens de script como Javascript ou Perl pertencem à camada de apresentação, da qual iremos falar em seguida.

2.2. Apresentação

Essa é uma das camadas mais importantes das aplicações, web ou não. É nela onde serão produzidas e enviadas todas as requisições à lógica Java. Nela também se concentram o gerenciamento de sessões, preferências salvas (cookies), navegabilidade, redirecionamento, single sign-on, eventos e efeitos gráficos. E quando falamos sobre lógica de negócio, coisas como adsense, pop-ups e outros recursos também podem ser usados dependendo da estrutura e do tipo de cliente esteja usando para apresentar a aplicação.

Para esta camada, inúmeros frameworks web podem ser utilizados para auxiliar no desenvolvimento e manutenção da mesma. Geralmente, no mundo de Java web, o que mais encontramos são páginas repletas de HTML, misturadas com JSP, Servlets, Expression Language (EL) e algumas bibliotecas de tags Java, como a JSTL (Java Standard Tag Library). As bibliotecas de tags Java ajudam a quebrar o tabu do uso indevido de código Java em páginas JSP, os famosos Scriptlets. Isso permite a construção de páginas mais limpas e legíveis, tanto para desenvolvedores quanto para designers que não entendem de Java. Além disso, temos um outro exemplo bem comum de framework web usado nesta camada: o JSF (Java Server Faces), este que muitas vezes é confundido com ferramenta ou libs que usamos dentro de um projeto Java web. JSF vai além disso; é uma especificação.

Uma ação muito comum ainda na comunidade é o uso “mais que inapropriado” dessa camada para inserção de regras de negócio e/ou persistência. Isso não é bem visto nem sob o ponto de visto programático, tampouco pelo gerencial e técnico.

2.3. Camada de Negócio

Existem inúmeras aplicações com diferentes regras de negócio sendo feitas dia pós dia. As mesmas regras ganham adicionais de complexidade há cada nova visita ao cliente para coleta de requisitos. Seja a aplicação complexa ou não, grande ou não, é necessário que a camada de negócio se (bem) adapte ao restante das camadas.

Essa camada representa o intermédio das demais na aplicação. É ela quem liga tudo que acontece na tela ao banco de dados, e além disso tem o papel de fazer validações, conversões, informes e críticas, tratamento de exceções, e etc.

É nessa camada também que começa a ser pensado a divisão do aplicativo em partes menores, a modularização. Modularizar a aplicação em componentes torna o reaproveitamento de código bem mais objetivo. A partir dessa abordagem também conseguimos construir software com baixo acoplamento e razoável coesão.

2.4. Camada de Persistência

Essa camada sempre ganha uma atenção especial na aplicação, uma vez que é a partir dela que temos disponíveis as funcionalidades de persistência (DMLs e DDLs) na base de dados. Persistência essa que faz comunicação direta, geralmente, com a camada de negócio.

A Figura 2 mostra como se divide basicamente essa organização, de modo que a “Data Layer” representa a camada de persistência. Nela alguns frameworks ORM como Hibernate, JPA e EclipseLink se fazem presentes de forma a otimizar o uso e funcionamento dessa camada.

Concluindo

Usar camadas em aplicações sejam elas web, desktop ou mobile permite que você foque tuas forças em coisas mais importantes, que não sejam fazer o que muitos já fizeram.

No mais, deixo aqui minhas experiências de que camadas, MVC, padrões e todo esse emaranhado de organização fazem uma grande diferença no final do processo.