Introducción a Quetzal

El surgimiento...

Hace varios años que vengo girando alrededor del tema de ser "productivo" en mi trabajo, y a su vez me aburre mucho "copiar y pegar" código y luego reemplazar, para hacer aplicaciones nuevas, sin hablar de los riesgos que esto implica. Así es que siempre he tratado de construirme algún framework, o herramientas que me ayudaran a evitar esta tediosa tarea.
Unos de mis primeros intentos fue por Marzo del 2002 con un proyecto de "generación de código" que se llamo "GenClases" y que realice en VB6 + XML + XSLT. Demás esta decir que fracasé en tanto que debía escribir las XSLT(o sea los templates) para hacer las transformaciones. Un trabajo que luego de cierto grado de complejidad se torna "inhumano".
Luego vino .Net, c#, CodeSmith, MyGeneration, NHibernate, Patrones, DDD, ASP.NET 2.0, AJAX etc. por lo que pasó un tiempo hasta que logre reacomodar la cabeza para insistir con el tema y finalmente pude volver a la tarea de hacer algo que me ayudara en la generación de mis aplicaciones.

Pero... que es Quetzal?

Quetzal es un framework de librerías desarrollado en C#, que junto a otras herramientas como NAnt y NVelocity, permite la creación de aplicaciones y sus multiples artefactos, a partir del código escrito para las clases del dominio de la aplicación.

Algunos antecedentes

Es dificil entender el "punto nodal" de Quetzal sin ver un panorama de las herramientas de "automatización" para la generación de aplicaciones.
Una primera aproximación es la de los "generadores de código". Angel "Java" López ha escrito muy, mucho y bien sobre el tema (y en castellano para colmo) lo que me ahorra de escribir unos buenos párrafos sobre esto.
Pero tambien hay frameworks, como "MonoRail" que van más allá de la generación del código y parte de su "trabajo" lo realizan de forma dinámica o en "runtime" como en el caso de la generación de los .hbm de NHibernate con "Castle ActiveRecord".
Otra mirada del asunto la encontrmos en "Naked Objects" para el mundo Java, con su "futura" versión optimizada para .net, donde solamente debemos escribir "una" capa (la del dominio) para tener la aplicación hecha. Y no sigo más para no aburrir y porque con esto me alcanza para marcar algunas diferencias en la visión de Quetzal.
Queda sin embargo un tema importate en todo esto : LOP o "Lenguajes Orientados a la Programación", una especie de "esperanto" para programar, pero me referiré a esto más adelante .

Los problemas de estos enfoques

En la mayoría de las estrategias de los "generadores de código" el modelo esta separado de la aplicación, siempre hay una metadata que define al dominio de la aplicación que es distinta del codigo de las clases, siempre debe sucederse una transformación con el consiguiente problema de el "gap"(distancia) posible entre el modelo de la metadata y el modelo de la aplicación. A esto debemos sumarle que pasa con el código "nuevo" agregado, ante una nueva generación, "partial class" y herencia juegan aquí su rol para garantizar la "sincronía", que si no esta prevista implica "fuertes" dolores de cabeza.
En cambio los frameworks como Mono Rail, tienen el problema de que estan "atados" a una "arquitectura" y en este caso tambien a una tecnología (NHibernate con ActiveRecord), entiendo que su uso no es excluyentes, pero implican un costo y pierde algo de la gracia de su uso.
El enfoque en cambio de Naked Object, que es el que más me simpatiza en términos de "productividad", implica escribir el dominio de una forma "extraña", definiendo las clases del dominio con los tipos que propone el framework, pudiendo implicar que ciertas actualizaciones del lenguaje impliquen la actualización previa del framework para su utilización. Tambien tiene su costo en el entrenamiento, si trabajamos con personas no entrenadas en el framework

Que sería entonces lo deseable de un generador de aplicaciones?

1. Poder escribir el modelo en el mismo código de la aplicación.
2. Que no implicara acoplamiento alguno con una determinada tecnología.
3. Que no usara otro tipo de clases para definir el dominio que nos impidan reutiliazar lo ya codificado y que la curva de aprendizaje sea leve.
4. Que no usen bases de datos para inferir el modelo, evitando así la impedancia entre objetos y tablas.

En la próxima entrada les presento a Quetzal.