Armando una aplicación usando AjGenesis (Parte 1)

Published on Author lopezLeave a comment

Este es la primera parte de un tutorial acerca de cómo usar AjGenesis, mi generador de código, open source, para generar una aplicación. La solución que quiero generar será una aplicación .NET en C#, pero en el camino agregaré ejemplos en VB.NET, PHP y Java, para que sirvan de “prueba de concepto” del poder de partir de un modelo abstracto, independiente lo más posible de la tecnología a usar.

Este es el primer paso que encaro hoy: escribir un modelo en archivos XML (podría escribirlos también en texto plano: la versión del trunk de AjGenesis soporta ambos tipos de serialización de los modelos).

Recuerden: el modelo a usar es libre, no sigue un esquema. La idea es que el modelo vaya emergiendo de las necesidades de cada uno, no de lo que yo escriba en este tutorial. Iremos refinando el modelo, paso a paso, enriqueciéndolo, haciéndolo más expresivo, tratando de separar la definición de la implementación. La serie de estos posts mostrará las decisiones que voy tomando. Quiero terminar modelando una aplicación empresarial: algo que contenga clientes, proveedores, facturas, pagos, etc. Comencemos por Customer (Cliente) y Supplier (Proveedor).

(Pueden bajar el código de este post desde AppExampleStep01.zip, son solamente 3 archivos XML)

Este es el contenido del archivo Customer.xml:

<Entity>
	<Name>Customer</Name>
	
	<Properties>
		<Property>
			<Name>Name</Name>
			<Type>Text</Type>
		</Property>
		<Property>
			<Name>Address</Name>
			<Type>Text</Type>
		</Property>
	</Properties>
</Entity>

Hay un archivo con contenido parecido en Supplier.xml. Noten que no hay un esquema a seguir: podemos agregar cualquier tag o atributo mientras que el resultado sea un documento XML bien formado. Iremos aprendiendo algunas restricciones mínimas que pide AjGenesis. Por ejemplo, reconoce que <Properties> es una lista de <Property> así que no aceptará fácilmente que pongamos algo distinto dentro de esa lista. Ahora, cada <Property> puede tener los atributos y elementos hijos que querramos. Podemos tener un elemento simple como <Name> o un elemento compuesto como <Property>. También podría haber escrito Name como atributo, tipo <Entity Name=”Customer”…. Vamos a ver que para AjGenesis, esto es lo mismo: al cargarlo en memory, el nombre, en el modelo, quedará referenciado como Project.Name, independientemente de cómo estaba escrito en el archivo original.

Uno de los principios que guiaron mis decisiones de diseño: el modelo serializado (XML, archivo de text, otros…) no debería hacerme doler los ojos (vieron esos archivos XML que son inentendibles de tanto namespaces y schemas?) Así, que tomé una convención para permitir que no todo el modelo tenga que estar en un solo archivo. Vean el Project.xml:

<Project>
	<Name>AjApp</Name>
	<Description>Building an Application using AjGenesis</Description>
	<Model>
		<Entities>
			<Entity Source="Customer.xml"/>
			<Entity Source="Supplier.xml"/>
		</Entities>
	</Model>
</Project>

 

El atributo Source es uno distinguido, tratado especialmente por AjGenesis: el contenido de ese atributo apunta a un archivo, relativo al archivo padre, que se carga en el modelo como si hubiera estado directamente ahí, en la rama donde aparece el atributo Source. El modelo en memoria, veremos, será un solo grafo de objetos, aunque serializado estuviera ocupando más de un archivo.

Próximos pasos, en siguientes post: cómo usar este modelo de AjGenesis para generar algunos archivos C#. Luego, generaremos Java, VB.NET, y algún proyecto más completo.

Nos leemos!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Leave a Reply

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