Esta DSL permite generar consultas SQL a partir de la definición de unas tablas y sus relaciones.
La he desarrollado sobre Visual Studio 2005, pero como todo es muy básico, supongo que aplica a versiones posteriores.
Este es el aspecto de la DSL
Así es como quedaría la Query generada.
Los elementos del modelo
Las clases
Representa una Query. Un diagrama puede tener una 0..N Queries.
Permitimos especificar un nombre y una descripción.
Representa cada una de las Tablas que tendrá la Consulta.
Tiene la propiedad Alias por si es necesario darle otro nombre a la tabla.
Una Query puede tener 0..N Tablas
Representa cada uno de los campos de una Tabla.
Cada tabla puede tener 0..N Campos.
La propiedad Name y Alias permite referenciar el nombre del campo.
La propiedad Select indica si el campo debe aparecer en la cláusula SELECT de la Query. Si es false, se utilizará sólo para especificar una condición.
Las condiciones de filtrado de la Query se especificarán en la propiedad FilterValue. En la imagen de ejemplo, se añadirá al WHERE de la SELECT la condición SHIP_COUNTRY=’SPAIN”. La propiedad DataType se utilizará para formatear adecuadamente el valor de la condición.
Las Relaciones
El modelo sólo podrá tener una Query como elemento primario.
La Query podrá tener una o varias Tablas.
y cada Tabla tendrá sus Campos.
Por último, las Tablas podrán tener relaciones entre ellas, y en cada relación, deben especificar un campo en cada tabla, mediante el cual se pueden relacionar.
Los elementos UI
Es una GeometryShape normal y corriente.
Hemos modificado este CompartmentShape indicando que tendrá un Custom Parent Element, para que mediante código podamos especificarle que su padre será el GeometryShape de la clase Query.
El conector tiene un par de Text Decorators para mostrar el Source y el Target Field de cada Tabla.
Customizations
Por defecto, en VS 2005 no se permite que un elemento del diagrama tenga como padre a otro elemento que no sea el propio diagrama.
El truco, es indicar en las propiedades del elemento hijo (el TableCompartmentShape en este caso) que vamos a especificar por código cuál será su padre.
Y en el código, le decimos que su padre será la clase Query.
Template
En la Template, todo el código es bastante simple. En la mayor parte se trata de recorrer los elementos del diagrama, para ir creando la Query.
Recorrer las Queries del Modelo
Recorrer las Tablas de cada Query y por cada Tabla, recorrer cada Columna
Quizá lo más complejo es lo de leer las propiedades de la relación.
TableReferencesTargetTables es la clase que representa la relación entre las tablas.
Esta clase expone el método estático GetLinksToSourceTables que devuelve las relaciones en las que la tabla especificada en el parámetro sea Origen, o tenga el rol “source”. Una vez que tengamos esta referencia, podemos leer el valor de las propiedades Source y Target, que son los campos por los que se relacionan las dos tablas.
Y para qué puede servir todo esto? Pues para además de generar la query, generar por ejemplo los procedimientos almacenados para las operaciones de Alta, Baja, Consulta y Modificación (CRUD), la capa de Acceso a Datos, incluso parte de la Lógica de negocio, Unit Tests, puede que hasta formularios.
Tiembla EF?
Great work !!! 😀
Salu2
No… si a mi tampoco me hace gracia teniendo el EF, pero ya sabes como andamos en mi proyecto… con el framework 2.0, VS 2005 y Source Safe…. a ver si ofreciendo algo de esto podemos innovar en algo.. XD