Grails en un entorno de desarrollo Java

Desde hace un año y desde Salenda, tengo el placer de desarrollar aplicaciones Grails para una institución pública en la que se trabaja en un entorno de desarrollo mayoritariamente Java. Mi intención con este post es explicar, desde mi humilde experiencia, como se puede introducir poco a poco este framework en un entorno de desarrollo de estas características sin ningún tipo de problema y con resultados satisfactorios. Hay ejemplos mucho más importantes como el de http://www.escueladegroovy.com/ y el ayuntamiento de Vitoria-Gasteiz, pero yo voy a aportar mi granito de arena. En este caso, la introducción de Grails se está haciendo poco a poco y, de momento es Grails quien se tiene que adaptar a los recursos del entorno de desarrollo al contrario de lo que ocurre en el Ayuntamiento de Vitoria-Gasteiz

Primero voy a explicar de qué recursos partimos:

• Servidores Tomcat y GlassFish
• Bases de datos Oracle e Ingres
• “Mega-Api’s” Java que son mapeos JPA de las anteriores bases de datos con sus Dao’s y las implementaciones de éstos.
• Escepticismo ante Grails
• …

Con este panorama, me plantean desarrollar la primera aplicación utilizando Groovy y Grails. Sólo especificaron qué querían tener y para cuándo, el cómo era cosa mía, eso sí, adaptándome a los recursos que existen. Si el resultado era satisfactorio se seguiría esa línea con otras aplicaciones.

Posibles problemas que nos podíamos encontrar o nos encontramos:

• Tiempo dedicado al aprendizaje de Groovy y Grails: mmmmmm…. ¿O minutos? En mi caso, ya había hecho cosas antes con Groovy y Grails pero cuando empecé, yo sólo había programado en Java y aprendí Groovy sobre la marcha: al principio empiezas sólo quitando “;” y con el tiempo vas descubriendo las capacidades de Groovy y Grails (los “finders” dinámicos, los “createCriteria”, los bucles, la definición de tipos y objetos en tiempo de ejecución, el manejo de listas, GORM, el uso de plugins…y así, un lago etc.) Sobre Grails…pues sabiendo J2EE no hay mucho más que aprender. Sigue una arquitectura Modelo-Vista-Controlador, y está construido sobre Spring e Hibernate pero nosotros no tenemos que preocuparnos de ficheros de configuración ni nada por el estilo. Realmente ahorramos tiempo.

• Sevidores: que queremos desplegar en Tomcat, pues añadimos el fichero context.xml para definir el datasource por JNDI y listo. Que queremos desplegar en GlassFish y también necesitamos definir el datasource por jndi pues no hay que hacer nada.

• Bases de datos: ningún problema, incluimos el .jar correspondiente y ya está.

• La aplicación utiliza dos bases de datos distintas – hay que definir dos datasources: pues uno en el datasources.groovy y el otro en el resources.xml, dentro del directorio de spring, ya sea especificando los datos de la conexión o por jndi

• Uno interesante: La aplicación no puede mapear directamente sobre la base de datos, las clases de dominio deben ser clases java de una de las “mega-api’s” y hay que utilizar sus Dao’s. Se me cayó el mundo encima de pensar que no podía utilizar GORM!! Pero bueno, vayamos por partes:

• • ¿Por qué esta restricción? “Porque esto ya estaba hecho“, “porque se ha invertido mucho tiempo en desarrollar las api’s“, “porque así está todo más organizado“, “porque así todas las aplicaciones acceden a la base de datos de la misma manera“…
  • Hacer que las clases de dominio sean clases de un api externo java: ningún problema, se tira del fichero hibernate.cfg.xml (en el directorio hibernate de la aplicación). En este fichero se dice cuáles son las clases del api que van a ser clases de dominio de la aplicación y a partir de ahí trabajamos normalmente.
  • ¿Cómo los convenzo de utilizar GORM? Cayó por su propio peso: Era mucho más rápido hacer consultas (que en esta aplicación había muchas y por bastantes criterios) con “finders” dinámicos y “createCriteria” que hacerlas sin GORM o en el propio api, ya que en un api genérico para varias aplicaciones no se van a definir consultas específicas de una aplicación. Además, así podíamos valernos del plugin “grails-ui” y de sus “datatables” así como de su paginación y ordenación automáticas.
  • Y yo fui feliz

• No se quieren incluir jar’s en directorio “lib” del proyecto, se quieren instalar dependencias. Pues se instalan:

install-dependency mysql:mysql-connector-java:5.1.5 –repository=http://download.java.net/maven/2

Conclusiones:

• Éxito en la integración
• Podíamos ver partes de la aplicación funcionando a corto plazo.
• Se llegó a los plazos, con tiempo de sobra.
• Con el uso de algunos plugins hemos ahorrado tiempo al tener que desarrollar ciertas funcionalidades.
• Se han podido empaquetar aspectos comunes a las aplicaciones en un plugin para así no tener que desarrollar/configurar éstas n-veces ( DRY – Don’t Repeat Yourself xD )
• Hemos conseguido convencer a la gente!
• ¡Ya hay varias aplicaciones Grails en marcha!

¡Si se quiere… se puede!