Arquitetura de Software e os Frameworks Java

É uma questão interessante. Na decisão de uma arquitetura para um projeto em Java, analisar as possibilidades de frameworks disponíveis. Eles são muitos. E a decisão vai influenciar diretamente no desenvolvimento, manutenção e no ambiente de produção. Acho que todo mundo já viu alguém falando que não gosta de Java justamente por ter muitas opções.

A 3 anos atrás, comecei a trabalhar no TI da Lojas Renner, e lá, assumi a tarefa de propor uma nova arquitetura, para modernizar o desenvolvimento existente na época. O que existia, era uma arquitetura usada por anos, que era um JSP que gerenciava o fluxo de cada requisição, e chamava uns EJBs que faziam o acesso ao banco de dados.

Naquela época o Struts comandava, mas eu preferia o WebWork por ser uma alternativa mais moderna e achava melhor. Mas eu não queria simplesmente colocar um framework para funcionar. Depois de várias análises, meu objetivo era que não fosse necessário re-escrever as regras de negócio se depois de um tempo a arquitetura mudasse de novo.

Existia também um fator importante. Os desenvolvedores não poderiam perder muito tempo com o desenvolvimento, pois eram os mesmos que estavam envolvidos nos processos da empresa. Por isso eu não poderia criar uma arquitetura muito complicada e cheio de burocracia.

Hibernate? Nem pensar. A equipe de banco tinha vetado qualquer tipo de geração dinâmica de SQL. "Seria pior para os servidores" diziam. Nesse momento o iBatis foi a melhor solução: SQL fora do código Java, SQL escrito pelos programadores e mapeamento objeto relacional. Tivemos alguns problemas com as chamadas de procedures, mas todos foram contornados.

Então criei a primeira versão do framework. Coloquei o WebWork, que chamava uma camada de serviço independente da Web, e esta acessava os DAOs do iBatis para chegar no banco. Os retornos eram em JSP, sem muitas frescuras, como as telas que eles faziam antes. Tive o cuidado apenas de criar alguns padrões de pacotes, e fiz isso de maneira bem rígida.

Funcionou bem, mas algumas coisas me incomodavam. Por exemplo, o mapeamento das ações do WebWork eram feitas em XML, e isso era um saco para os desenvolvedores, que se enrolavam, e gerava conflito na hora de fazer o commit dos arquivos. Com algum desenvolvimento, comecei a ver que o WebWork estava sendo subutilizado, e ainda gerando mais trabalho. Decidi que faria uma solução melhor. Criei um mini web framework, usando o padrão Command, e em pouco tempo coloquei no ar, no lugar do WebWork. Com a estrutura das classes que eu tinha criado, nenhuma classe que já tinha sido escrita teve que ser alterada, eu tirei o webwork fora e coloquei minha solução sem mudar nada. A única diferença é que o desenvolvimento não precisava mais configurar as ações. A grosso modo, o framework "adivinhava" qual classe chamar, e depois "adivinhava" qual JSP iria retornar para criar o HTML de retorno.

Nesse ponto foi interessante. Porque os desenvolvedores tinham se acostumados a criar as ações no XML e meio que se questionaram sobre como o framework sabia a classe Java correta para chamar. Isso foi o Convention over Configuration em ação, que na época o WebWork não suportava, e que se encaixou perfeito no meu objetivo, de facilitar o desenvolvimento.

Com meu código recebendo todas as requisições antes de repassar para as ações, comecei a ter idéias para aprimorar e facilitar o desenvolvimento. E uma delas foi o tratamento dos parâmetros recebidos e enviados. Dediquei um tempo a essa questão, e consegui esconder toda complexidade de tratamento e conversão dos parâmetros que iam ou vinham do HTML. No sistema inteiro, eliminei todas as conversões, e com isso consegui fazer o sistema ficar localizável. Basicamente um objeto com um atributo Date, era convertido para String de dd/mm/yyyy, mas apenas se o Locale fosse em pt-BR, se fosse em en-US a conversão era para mm-dd-yyyy. Isso estava valendo para números e qualquer outra tipo internacionalizável.

Isso deu um "gás" legal, e o tratamento dos parâmetros acabou sendo meu xodó. A questão que quero levantar é, se eu tivesse continuado como WebWork, isso também seria possível, mas provavelmente seria mais trabalhoso, e mais complexo para ser executado. Nem sempre um framework, por melhor se seja, vai resolver o meu problema da melhor maneira.

O melhor framework do mercado para uma determinada função, acaba sendo o mais genérico, acaba sendo um canhão, muito bom para levar para a guerra. Mas as vezes para resolver um problema específico acaba não sendo a melhor solução. É preciso ter cabeça aberta para enxergar as reais alternativas.

Quando me desliguei da Lojas Renner, a um ano atrás mais ou menos, a arquitetura que tinha construído já tinha evoluído bastante. Estava sendo usado por cinco empresas parceiras inclusive eu já tinha repassado o treinamento para uma delas.

Ficou como uma ótima experiência, e principalmente sobre o uso indiscriminado de ferramentas disponíveis. Uma detalhe que eu acertei meio que “sem querer” foi o cuidado com a equipe que iria usar a solução que eu estava desenvolvendo. Eu era o arquiteto que não programava. Apesar de ter feito algumas telas de testes, somente levando meu computador para o lado de quem realmente estava usando pode fazer com que eu tivesse a real visão do que era melhor para o desenvolvimento.