{"id":330,"date":"2009-03-18T19:24:47","date_gmt":"2009-03-18T22:24:47","guid":{"rendered":"https:\/\/devkico.itexto.com.br\/?p=330"},"modified":"2009-03-18T19:24:47","modified_gmt":"2009-03-18T22:24:47","slug":"grails-e-codigo-legado-rejuvenesca-seu-codigo-legado","status":"publish","type":"post","link":"https:\/\/devkico.itexto.com.br\/?p=330","title":{"rendered":"Grails e c\u00f3digo legado – rejuvenes\u00e7a seu c\u00f3digo legado!!!"},"content":{"rendered":"

\"\"<\/a>Um dos aspectos mais fenomenais do Grails consiste no reaproveitamento de c\u00f3digo legado. \u00c9 muito bacana ter todo o ganho de produtividade que o framework nos oferece, no entanto, este ganho s\u00f3 se torna REAL com reaproveitamento de c\u00f3digo. E \u00e9 neste ponto que Grails se torna REALMENTE interessante para o desenvolvedor que trabalha com Java.<\/p>\n

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

Iniciei com JSF. Criei a aplica\u00e7\u00e3o no Netbeans, inclui no projeto todos os arquivos jar que precisava (in\u00fameros: inclua ai todos os arquivos de depend\u00eancia do Spring + Hibernate e saber\u00e1 do que estou falando) e comecei o trabalho. Momentos depois, a aplica\u00e7\u00e3o come\u00e7ou a dar problemas: o Tomcat havia come\u00e7ado a “implicar” com meu arquivo de configura\u00e7\u00e3o do faces, o que me deu MUITA pregui\u00e7a. Foi quando algo me veio \u00e0 cabe\u00e7a: uma aplica\u00e7\u00e3o feita em Grails n\u00e3o precisa ter classes de dom\u00ednio!<\/strong><\/span><\/p>\n

Sendo assim, criei uma nova aplica\u00e7\u00e3o feita em Grails e, ao inv\u00e9s de utiliz\u00e1-lo como um stack completo, o que costuma ser feito na maior parte das vezes, optei por trabalhar apenas com os controladores. E n\u00e3o \u00e9 que deu certo?<\/p>\n

O procedimento que segui foi basicamente o seguinte:<\/p>\n

1. Criar um novo projeto Grails e, em seguida, anular as configura\u00e7\u00f5es de acesso a base de dados. <\/strong><\/p>\n

Neste ponto: a \u00fanica a\u00e7\u00e3o necess\u00e1ria a fazer consiste em editar o seu arquivo DataSource.groovy para que fique exatamente como o descrito abaixo:<\/p>\n

\r\n\r\ndataSource {\r\n\r\n}\r\nhibernate {\r\n\r\n}\r\n\/\/ environment specific settings\r\nenvironments {\r\ndevelopment {\r\ndataSource {\r\n}\r\n}\r\ntest {\r\ndataSource {\r\n}\r\n}\r\nproduction {\r\ndataSource {\r\n}\r\n}\r\n}\r\n\r\n<\/pre>\n
Importante: a altera\u00e7\u00e3o deste arquivo de configura\u00e7\u00e3o \u00e9 opcional. No entanto, \u00e9 uma boa id\u00e9ia alter\u00e1-lo, pois voc\u00ea n\u00e3o ir\u00e1 precisar do HSQLDB rodando a toa por tr\u00e1s dos panos, n\u00e3o \u00e9 mesmo?<\/p>\n
2. Copie todos os seus arquivos .jar que voc\u00ea necessite para dentro do diret\u00f3rio lib de sua aplica\u00e7\u00e3o<\/strong><\/p>\n
Neste caso, por arquivos .jar, deve ser entendido o seu c\u00f3digo legado e suas depend\u00eancias. E ai \u00e9 que a coisa fica interessante: como Grails j\u00e1 v\u00eam com o stack completo, voc\u00ea basicamente s\u00f3 precisar\u00e1 incluir neste diret\u00f3rio, al\u00e9m do seu c\u00f3digo legado, uma ou outra biblioteca que sua aplica\u00e7\u00e3o venha a utilizar.<\/p>\n
Caso sua aplica\u00e7\u00e3o utilize algum dos frameworks abaixo, voc\u00ea nem sequer precisar\u00e1 copiar os arquivos jar necess\u00e1rios para dentro do diret\u00f3rio lib. Na realidade, para evitar conflitos, \u00e9 ideal que voc\u00ea n\u00e3o os copie. Muito bem: vamos a lista dos frameworks:<\/p>\n
Sitemesh, Hibernate, Sprng, Log4J, JUnit, Ant, Commons (boa parte do Apache Commons j\u00e1 vem com o Grails), Xalan, Xerces, Hsqldb.<\/p>\n
Como pode ser visto, a quantidade de arquivos de depend\u00eancia com os quais voc\u00ea venha a se preocupar diminui bastante neste momento. No meu caso, s\u00f3 precisei copiar o driver JDBC para o MySQL e o jar do JExcel (al\u00e9m, \u00e9 claro, do meu c\u00f3digo legado).<\/p>\n
Dica: navegue pelo diret\u00f3rio lib da sua instala\u00e7\u00e3o do Grails. Voc\u00ea perceber\u00e1 que talvez eu n\u00e3o tenha mencionado todas as bibliotecas que o Grails utiliza!<\/p>\n
3. N\u00e3o tem passo 3!!!<\/strong><\/p>\n
Finalizado este processo, tudo o que voc\u00ea precisa fazer daqui pra frente ir\u00e1 consistir em trabalhar apenas com os controladores de sua aplica\u00e7\u00e3o, que dever\u00e3o, por sua vez, acessar diretamente seu c\u00f3digo legado, e pronto: voc\u00ea ter\u00e1 reaproveitado 100% do seu c\u00f3digo e ainda ter\u00e1 tido no final das contas um ganho de produtividade gigantesco usando apenas a parte dos controladores do Grails!<\/p>\n
A grande dica para a finaliza\u00e7\u00e3o de sua aplica\u00e7\u00e3o \u00e9 a seguinte: esque\u00e7a o GORM!<\/strong><\/p>\n
Vantagens com rela\u00e7\u00e3o aos demais frameworks<\/h2>\n
\"\"<\/a>Nesta experi\u00eancia, ficaram n\u00edtidas para mim algumas vantagens desta abordagem com rela\u00e7\u00e3o ao procedimento tomado at\u00e9 ent\u00e3o, que consistia em utilizar um framework mais tradicional como JSF ou Struts. Seguem as vantagens que observei:<\/p>\n