Grails e código legado – rejuvenesça seu código legado!!!

Um dos aspectos mais fenomenais do Grails consiste no reaproveitamento de código legado. É muito bacana ter todo o ganho de produtividade que o framework nos oferece, no entanto, este ganho só se torna REAL com reaproveitamento de código. E é neste ponto que Grails se torna REALMENTE interessante para o desenvolvedor que trabalha com Java.

Nesta semana precisei criar uma nova aplicação web que, na realidade, não passava de uma interface para um sistema legado. O que eu tinha então: todos os jars que compunham a aplicação e uma escolha a fazer: qual framework utilizar: JSF, Struts, apenas servlets (um momento de insanidade, concordo)?

Iniciei com JSF. Criei a aplicação no Netbeans, inclui no projeto todos os arquivos jar que precisava (inúmeros: inclua ai todos os arquivos de dependência do Spring + Hibernate e saberá do que estou falando) e comecei o trabalho. Momentos depois, a aplicação começou a dar problemas: o Tomcat havia começado a “implicar” com meu arquivo de configuração do faces, o que me deu MUITA preguiça. Foi quando algo me veio à cabeça: uma aplicação feita em Grails não precisa ter classes de domínio!

Sendo assim, criei uma nova aplicação feita em Grails e, ao invés de utilizá-lo como um stack completo, o que costuma ser feito na maior parte das vezes, optei por trabalhar apenas com os controladores. E não é que deu certo?

O procedimento que segui foi basicamente o seguinte:

1. Criar um novo projeto Grails e, em seguida, anular as configurações de acesso a base de dados.

Neste ponto: a única ação necessária a fazer consiste em editar o seu arquivo DataSource.groovy para que fique exatamente como o descrito abaixo:

dataSource {

}
hibernate {

}
// environment specific settings
environments {
development {
dataSource {
}
}
test {
dataSource {
}
}
production {
dataSource {
}
}
}

Importante: a alteração deste arquivo de configuração é opcional. No entanto, é uma boa idéia alterá-lo, pois você não irá precisar do HSQLDB rodando a toa por trás dos panos, não é mesmo?

2. Copie todos os seus arquivos .jar que você necessite para dentro do diretório lib de sua aplicação

Neste caso, por arquivos .jar, deve ser entendido o seu código legado e suas dependências. E ai é que a coisa fica interessante: como Grails já vêm com o stack completo, você basicamente só precisará incluir neste diretório, além do seu código legado, uma ou outra biblioteca que sua aplicação venha a utilizar.

Caso sua aplicação utilize algum dos frameworks abaixo, você nem sequer precisará copiar os arquivos jar necessários para dentro do diretório lib. Na realidade, para evitar conflitos, é ideal que você não os copie. Muito bem: vamos a lista dos frameworks:

Sitemesh, Hibernate, Sprng, Log4J, JUnit, Ant, Commons (boa parte do Apache Commons já vem com o Grails), Xalan, Xerces, Hsqldb.

Como pode ser visto, a quantidade de arquivos de dependência com os quais você venha a se preocupar diminui bastante neste momento. No meu caso, só precisei copiar o driver JDBC para o MySQL e o jar do JExcel (além, é claro, do meu código legado).

Dica: navegue pelo diretório lib da sua instalação do Grails. Você perceberá que talvez eu não tenha mencionado todas as bibliotecas que o Grails utiliza!

3. Não tem passo 3!!!

Finalizado este processo, tudo o que você precisa fazer daqui pra frente irá consistir em trabalhar apenas com os controladores de sua aplicação, que deverão, por sua vez, acessar diretamente seu código legado, e pronto: você terá reaproveitado 100% do seu código e ainda terá tido no final das contas um ganho de produtividade gigantesco usando apenas a parte dos controladores do Grails!

A grande dica para a finalização de sua aplicação é a seguinte: esqueça o GORM!

Vantagens com relação aos demais frameworks

Nesta experiência, ficaram nítidas para mim algumas vantagens desta abordagem com relação ao procedimento tomado até então, que consistia em utilizar um framework mais tradicional como JSF ou Struts. Seguem as vantagens que observei:

• Reaproveitamento total de código legado: reparem que em momento algum precisei recompilar coisa alguma. Lidei aqui apenas com as camadas de visualização e controle.
• Sem arquivos de configuração. Já sofreu com o maldito arquivo de configuração do JSF ou Struts? Já penou com o web.xml? No caso do Grails, eu nem sequer me lembro de configurar qualquer coisa que não seja o acesso a dados!
• Rejuvenescimento do código legado: há momentos nos quais olho para o meu código Java e, em seguida, ao olhar para o meu código Groovy, tenho a impressão de que o mesmo encontra-se velho.
  Ao trabalhar com Grails, estou utilizando código Groovy para acessar meu código Java.
  Se assim como eu você também já está um pouco entediado em codificar na lingua mãe, Grails cai como uma luva.
• Facilidade de deploy: como não preciso me preocupar com tantos arquivos .jar, os meus problemas de deploy práticamente acabaram. Basta executar grails war e pronto. Lá está o war que precisava!
• Controladores realmente simples. Basta se lembrar do código que você escreve usando JSF ou Struts pra ver a diferença. No caso do Grails, é realmente simples: sem mapeamentos, sem regras: apenas closures simples relacionadas a arquivos de visualização igualmente simples.
• Filtros simples! Nada de implementar ou extender classes ou alterar arquivos de configuração!
• É Grails! Este para mim é o ponto mais importante: eu tenho todo o ganho de produtividade do Grails com meu código legado!

E aqui entra uma conclusão paradoxal: Grails sem o GORM acessando seu código fonte legado é ainda mais poderoso do que com o GORM. Por que isto? Simples: porque o reaproveitamento de código Grails não é a coisa mais simples do mundo. Se você cria por exemplo uma aplicação A em Grails, e em seguida quer reaproveitar parte do seu código em um projeto B, as coisas já se complicam. No entanto, se você tem sua camada de negócio bem organizada, reaproveitá-la no Grails é simples!