Spring Roo


Introducción

Spring Roo es una herramienta de desarrollo rápido de aplicaciones Java que pertenece al portfolio de aplicaciones de SpringSource.
El autor, Ben Alex define el objetivo de Roo como:
Roo's mission is to fundamentally and sustainably improve Java developer productivity without compromising engineering integrity or flexibility.

He de reconocer que me ha costado bastante decidirme a probarlo ya que lo encasillaba entre los generadoes de código convencionales que nunca han sido de mi agrado. Sin embargo, debido a principalmente los comentarios positivos de profesionales a los que tengo en gran estima y a que, de algún modo, un generador de código convencional no encajaba en SpringSource, finalmente no he podido resistirme más. Después de leer la documentación y realizar unas pruebas me he quedado realmente impresionado. Spring Roo es capaz de separar completamente el código que un programador debe de escribir del código tedioso y repetitivo que realmente puede automatizarse. Tanto es así que los programadores (que no sientan curiosidad) nunca verán el código generado como parte del proyecto.


Usabilidad


El primer punto a favor de Spring Roo es su interfaz, un interprete de comandos con autocompletado, muy similar a las shells de *nix con readline.
Esto nos va a permitir crear scripts propios para generar el esqueleto o partes de la aplicación con la flexibilidad y la productividad propia de los intérpretes de comandos. Además el interprete es realmente intuitivo. Basta pulsar [tab] para ver las opciones que disponemos o introducir el comando 'hint' para obtener indicaciones sobre el próximo paso a seguir. Por supuesto, podemos seguir usando nuestro IDE favorito para el desarrollo. Spring Roo vigila los cambios que hacemos en el código y toma las medidas oportunas en caso de que deba hacerlo.


Funcionalidad


Spring Roo está basado en una arquitectura modular que permite construir distintos tipos de aplicaciones según los módulos que utilicemos. Sin embargo, en principio, está bastante orientado a la creación de aplicaciones web basadas en Spring MVC en la capa de presentación y una capa de modelos del dominio persistentes mediante JPA.

Los modelos del dominio encapsulan tanto lógica de negocio como la lógica de persistencia, un patrón de ORM, Active Record, descrito por Martin Fowler en P of EAA como:
"An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data."

Representa una simplificación importante sobre la clásica arquitectura de de tres capas donde se han suprimido la capa de servicios (Service Layer) y la capa de acceso a datos (DAO, Repository) que suelen ser una sobrecarga innecesaria en proyectos web de tamaño medio o pequeño.

La productividad de la arquitectura basada en registros activos ha sido probada considerablemente en el pasado, por ejemplo en frameworks como Ruby on Rails y en mi opinión es un gran acierto que Spring Roo la adopte como base sin desdeñar que en el futuro puedan incorporarse módulos que permitan arquitecturas más complejas, adecuadas a proyectos de mayor tamaño.

No hace mucho pude comprobar las consecuencias de la sobredimensionar la aquitectura en los proyectos de software. La empresa impuso unas normas de arquitectura y codificación bastante rígidas y de aplicación genérica a todo tipo de proyectos J2EE: Arquitectura de tres capas, entidades sin comportamiento, incluir toda la lógica de negocio en los servicios, intercambiar exclusivamente DTOs entre capas... El resultado fué (en mi opinión) desastroso. Proyectos simples con presupuestos holgados fracasaron estrepitosamente. Apostar por la arquitectura más simple que pueda funcionar es la opción ganadora.

Otra ventaja a tener en cuenta es que suele ser bastante más asequible para equipos de desarrollo con un porcentaje alto (o muy alto) de programadores con poca experiencia, como por ejemplo, las factorías de software. El lanzamiento de la aplicación es un autentico relampágo y la herramienta se hace cargo de muchas de las tareas que, a pesar de ser monótonas para programadores experimentados, suelen ser barreras difíciles de pasar para los nuevos por la cantidad de conceptos que manejan.


Estructura interna

Spring Roo se divide en un núcleo principal y los módulios "add-on". El núcleo lo forman el intérprete de comandos, un gestor del sistema de ficheros, un monitor del sistema de ficheros, abstracción del classpath, analizador del árbol sintáctico (Abstract Sintax Tree - ATS), La interfaz del sistema de construcción del proyecto, el modelo de metadatos, el gestor de procesos y el servicio de arranque y utilidades.

Salvo que estemos interesados en desarrollar en el propio corazón de Spring Roo, como usuarios lo que realmente nos importa son los módulos añadidos. Estos son los que nos dan la funcionalidad que queremos añadir a nuestra aplicación.

Es posible añadir nuevos módulos y es esperable que en poco tiempo los usuarios compartan los módulos que han desarrollado.

Arquitectura




Introducciones de AspectJ (AspectJ inter-type declarations - IDT)

Hasta ahora en todos los generadores de código que he podido probar cambiabas duros por pesetas. Si utilizabas un generador de código para crear los modelos de entidades de la base de datos, por ejemplo, el modelo generado carecía de las características propias de un modelo natural OO y acababa comprometiendo el proyecto. El control sobre el código generado era escaso y dificilmente se podían especificar las jerarquías o las interfaces que el código generado debia implementar. Finalmente se generaban clases java sobre las que el programador debía introducir más código dando lugar a situaciones difíciles de mantener.

Spring Roo evita estos inconvenientes de una forma extremadamente elegante. Mediante el uso de IDTs. Todo el código que genera Roo se encuentra separado de las clases java sobre las que el programador desarrolla, en las introducciones de AspectJ (con extensión .aj). En tiempo de compalición se unen las clases java con las introducciones para crear un único fichero .class. Puesto que la clase es idéntica a como sería si el programador hubiera escrito todo el código el mismo, todas las ventajas del lenguaje Java y de los IDEs de desarrollo funcionan a la perfección. El programador puede ignorar por completo el código generado en los IDTs. Estos contiene conceptos y funcionalidades que se han delegado en Roo y es Roo el encargado de mantenerlo.

Referencias