Hablamos sobre experiencias personales en el uso de generación de código p/construir aplicaciones y sobre temas relacionados. Voy a tratar de hacer un resumen de los temas que tocamos. Visiten el blog de Claudio, que en cualquier momento escribe algo también:
Experiencias personales de uso
Claudio comentó sobre su proyecto
Quetzal de generación de código. Yo comenté sobre una experiencia de hace unos años
usando AjGénesis en un proyecto real y la de hace unas semanas, donde a partir de un modelo muy simple, generamos una solución web mvc con las características que venimos usando últimamente (service layer, domain model, repository, log4net, structure map, manejo de errores c/páginas amigables, etc). También generamos los scripts de nAnt p/integración continua con cruise control y deploy automatico al ambiente de QA.
Modelos abstractos
Dijimos que algo destacable de la generación de código es trabajar con modelos abstractos. A partir del modelo, es posible generar código con una herramienta (ej:
AjGénesis) o en runtime (ej: mapeos de
nhibernate). De hecho hicimos extensible el concepto a no solo generar código, sino cualquier artefacto de texto como pueden ser script de base de datos, archivos de mapeo nhibernate, archivos de configuración, etc.
Una distinción importante para hacer en el modelo es separar el modelo de la tecnología o aspectos de implementación (como podrían ser paths, lenguage de programación, etc).
Algo interesante de AjGénesis es que el modelo se puede cargar de cualquier lado. Por ejemplo se podría cargar una parte del modelo a partir de las clases de una dll. Y luego completar ese modelo con más información, cómo por ejemplo que campos son requeridos p/armar un ABM.
Otra cosa que puede servir a la hora de diseñar un modelo es la de favorecer
convención sobre configuración, para que sea menor la cantidad de cosas a definir en el mismo. Por ejemplo, podría asumir que todos los campos de mis entidades son requeridos y especificar puntualmente cuales no.
Mantenimiento
Uno de los problemas que a veces se presenta, es que después de generar el código surgen necesidades que me obligan a cambiarlo. Si el cambio lo hacemos directamente en el código, este gap es costoso de mantener y me pierdo de volver a cambiar el modelo y regenerar nuevamente.
Una manera de lidiar con esto vimos que es importante crear buenas abstracciones que separen la parte del problema que puede ser resuelta con generación de código, de la que no. De esa forma, hacer un cambio se traduce a modificar el modelo y volver a generar el código.
Cuando conviene usar generación de código?
Pregunta de respuesta fácil, depende... De qué depende? eso es más difícil de responder. La generación de código es una manera de automatizar tareas repetitivas, por lo que si hay algo que se repite muchas veces, podría considerarla como una buena opción.
Criterios de evaluación
Conversamos también sobre algunos criterios para evaluar una herramienta de generación de código:
- El código generado debería ser el mismo que escribiría a mano sin usar la herramienta.
- Una prueba ácida sería que a partir del mismo modelo, debería ser posible generar código para otra tecnología.
- El modelo a definir debe ser libre.
- Posibilidad de cargar este modelo de cualquier lado: xml, excel, txt, dll, tablas, etc.
Pueden ver mucha más información sobre este tema en el blog de
@ajlopez:
saludos!