Generando y regenerando texto y código con AjGenesis

En estos días de Junio, se ha desarrollado el interesantísimo congreso de generación de código (digamos, “el mundial” del Code Generation), con un programa envidiable:


Code Generation 2009 – Daily Event Programme


Encuentro en Twitter



(uso TweetDeck, con search “code generation”)


el enlace a este post de Steven Kelly (de MetaCase) sobre


Code Generation 2009 round-up


donde levanta y comenta impresiones sobre la conferencia. Curiosamente (o no, ya a esta altura), Kelly también usa Twitter para tomar feedback:


EelcoVisser: keynote by @markusvoelter and Steven Kelly at #cg2009: great overview of issues in model-driven development

 


HBehrens: Steven Kelly at #cg2009 keynote: “wizard based generators create a large legacy application you’ve never seen before”

 


A esta última referencia, Kelly comenta y responde:


The reference was to vendor-supplied wizards, often found in IDEs or SDKs, that create skeleton applications for you based on your input. Since the vendors take pride in just how much boilerplate they can spew out, you’re left with a mass of generated code that you’ve never seen before, but must extend with your own code. Worse, you’re responsible for maintaining the whole ensuing mixture, and there’s no chance of re-running the wizard to change some of the choices — at least not without losing or invalidating the code you’ve added. That’s in sharp contrast with generation in DSM, where your input is in the form of a model which you can edit at any time. You get the speed of generation but can remain at a high level of abstraction throughout


Con DSM se refiere a Domain Specific Model. Pueden ver mis enlaces en http://delicious.com/ajlopez/dsm


Más info visitando el DSM Forum


Mi proyecto de código abierto AjGenesis está basado en modelo, en modelos de libre definición, justamente, orientados al dominio que uno quiera modelar. No son modelos gráficos, que son más “fancy”, pero hasta ahora, me han resultado útiles y flexibles. Traduciendo la cita de arriba, una de las quejas de Kelly es que hay herramientas que generan código, como un wizard dentro de un entorno de desarrollo, pero luego, cuando trabaja agregando código propio en la solución, ya no puede volver a regenerar código. Y que él ve una solución si partimos de un modelo específico de dominio. El modelo a partir puede ser la base de datos, un modelo abstracto de entidades, un modelo más orientado al sistema que estamos tratando de construir (me imagino modelos dedicados a CRM, o a mercados aún más verticales).


Bueno, el tema da para discutir. Prácticamente, ningún modelo produce todo lo que queremos, así que tenemos que dejar en nuestra aplicación, lugares, puntos de extensibilidad manual, forma de agregar código nuestro, sin que tengamos que perder lo generado. Y que sigamos teniendo la posibilidad, al cambiar el modelo inicial, de volver a generar la parte automática, sin perder lo agregado manualmente.


Desde hace algunos años, incluyo este “slide” en mis charlas sobre el tema. Explico que uno no genera todo, y que tiene que estar claro, cuales archivos de texto son generados, y luego regenerados desde el modelo cuantas veces uno quiera, cuáles son generados de una sola vez, y cuáles son agregados manualmente:



Uno tiene que decidir qué genera desde el modelo, y qué genera o agrega manualmente. Me encontrado con gente que utilizó AjGenesis sólo para generar los procedimientos almacenados. En el proyecto Medusa (que mencioné en mi post


Generación de código con AjGenesis para Mere Mortals Framework


)


estamos adoptando una solución en el sentido de la figura. Cuando lanzamos la generación automática desde el modelo, que incluye:


- Generación de scripts de generación de las tablas
- Generación de los procedimientos almacenados
- Generación de un proyecto de Business Objects (como pide el Mere Mortals Framework)
- Generación de una aplicación web ASP.NET (usando nuevamente el Mere Mortals Framework, por ejemplo, sus controles web)


hemos codificado las tareas, de tal forma que:


- Hay archivos que siempre se generan (se “pisa” la anterior versión, pero solamente si la nueva tiene un contenido distinto)
- Hay archivos que no se generan si ya existen (pocos archivos, que se han decidido ser “one shoot”, generados de una sola vez, y no más)
- Hay archivos que se respetan y no se generan (archivos que vamos agregando a los proyectos que vamos armando)


Estamos usando .NET. En el caso 2, caen las clases parciales, que es una forma de seguir especificando una clase, en un archivo adicional al original. En otras tecnologías, podríamos generar un archivo ClaseBase generado automáticamente, y un ClaseReal donde pudiéramos luego poner todo nuestro código manual.


Con esta estrategia, hemos alcanzado hasta ahora, gran parte de lo que imaginaba en la figura de arriba: poder generar siempre desde el modelo, sin tener que perder lo que ya tenemos.


Nos leemos!


Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10673, 2643, 6145. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>