Cooperator Modeler

Introducción

Cooperator Modeler es nuestra herramienta de modelado y generación de código, en esta página vamos a explicar que significan cada una de las opciones que nos provee. Lo primero que vemos al cargar la herramienta son unos botones en la parte superior:

modelertopbuttons.jpg

New model:
Permite crear un modelo nuevo, abre el un cuadro de dialogo para conectarse a una nueva base de datos para hacer ingeniera inversa e inferir el modelo.

Reconnect:
Este botón permite reconectarse a la base de datos (cambiar la cadena de conexión), de un modelo existente. Esto es particularmente útil, cuando un team de desarrollo comparte el archivo de modelo (.coop) pero cada uno tiene una base de datos local. O también puede ser útil si se reinstala la base de datos en otro server, o si se modifican permisos en la base, etc…

Refresh:
Es utilizado para actualizar el modelo. Si utiliza para actualizar nuestro modelo leyendo nuevamente la base, pero sin perder toda la personalización que hagamos hecho en el mismo. (Cosa que pasaría si se crea un nuevo modelo)

Code Generation:
Este botón abre el cuadro de diálogo para la generación de Stored Procedures y los proyectos de nuestra aplicación.

Quick Generation:
Realiza la generación de Stored Procedures, Clases y proyectos y actualización de los mismos con un solo click. Se usan las opciones utilizadas por última vez en Code Generation

Load Model:
Como el modelo se guarda en un archivo (.coop), con este botón nos permite abrir un modelo guardado en el disco.

Save Model:
Con esta opción se graba el modelo actual en el disco (arhivo .coop)

Change Selection:
Cuando hay muchas tablas en una base de datos, esta opción cambia la posibilidad de generar o no, las entidades para las tablas, en vez de ir haciendo click en cada tabla para marcarla o desmarcarla. Este botón cambia el estado de seleccionado a no seleccionado y viceversa

About:
Muestra los créditos de la aplicación.

Exit:
Sale del programa.

Conectando con la base de datos:

Cuando se elige un nuevo modelo, aparece este cuadro de dialogo:

modeler_newmodeldialog2.jpg

Si los servidores SQL están publicados, se pueden obtener con el botón Find Servers, sino puede escribir el nombre del servidor a mano. Una vez obtenido el servidor, apretando el botón Get Databases, nos da la opción de elegir una con el botón Ok. Por defecto usa seguridad integrada, si usted utiliza otro tipo de configuracion en su servidor, puede pegar la cadena de conexión que usted utilice sobre el cuadro de texto, y apretar el botón Ok.

Trabajando sobre el modelo:

Bien llegamos al punto mas importante y es la pantalla principal de Cooperator Modeler, desde donde nos permite editar el modelo:

modeler_mainwindow.jpg

Lo primero que observamos es que tenemos un nodo a la izquierda por cada tabla en la base de datos, y a la derecha tenemos propiedades que podemos editar por cada nodo. Notemos que cada nodo también tiene otros sub-nodos donde aparecen entre otras cosas los campos de las tablas. Además si se selecciona un nodo del primer nivel (nodo tipo Objeto/Entidad), las opciones de la derecha, son diferentes a que si elegimos una nodo del segundo nivel (nodo tipo Propiedad), debido a que son nodos de distinta naturaleza.

Nodos del tipo Objeto/Entidad

Bien, comenzaremos explicando que representa cada opción (del panel de la derecha) para los nodos del tipo Objeto/Entidad. Esto aparece en el panel de la derecha cuando se selecciona un nodo:

modeler_tableoptions.jpg

Cache Duration:
Es el tiempo en minutos, que este objeto o entidad permanecerá en la cache sin que vuelva a obtenerse de nuevo desde la base de datos.

GenerateAs:
Es el nombre con el cual queremos que se genere el objeto o entidad para esta tabla. Por defecto tiene el nombre de la tabla, pero se puede modificar para cambiarlo según se desee. De esta forma, en nuestra base podemos tener una tabla llamada stk_customer, pero en nuestra aplicación la entidad correspondiente se llamará Customer.

GenerateAsChildOf:
Esta propiedad permite definir las composiciones de las entidades. Por ejemplo, si la entidad Order tiene como composición una colección de detalles, debemos ir al nodo Order Detail, y marcarlo como “ChildOf” Order.
Aquí no hay que confundir esta opción con la posibilidad de contar con distintas asociaciones en nuestras entidades. Esta opción solo se usa definir las posibles composiciones, esto es, los objetos “hijos” que forman parte de una entidad. Ejemplo: La entidad Order, estará compuesta por Order y Order Details, y se puede acceder a sus detalles así:

myOrder.OrderDetailCollection…

Pero la entidad Order, puede también tener una asociación a Customers y acceder al cliente dueño de una orden así:

myOrder.Customer…

Pero la diferencia entre estas dos agregaciones, es que OrderDetail es “parte” de de la entidad Order (es una composición), cuando se guarda una Order, se graba automáticamente también sus detalles, se define con GenerateAsChildOf, mientras que Customer, es solo una asociación en la entidad. Cuando se graba una Order, se graban sus composiciones (OrderDetail ) y no sus asociaciones (Customer, en este ejemplo).

GenerateAsReadOnly:
Hay algunas tablas que solo cumplen funciones de enumeración. Esto es, solo están para asegurar la integridad referencial y servir como referencia a otras tablas, pero no guardan datos sensibles. Por lo general, esta tablas tienen la forma: Id, Description, tienen muy poco registros y raramente se actualizan. Ejemplos de esta tabla son Region, o Territories.
Este tipo de tablas pueden marcarse con ReadOnly y Cooperator Framework automáticamente la primera vez que se necesite un objeto de ese tipo, leerá todos los registros, se guardará una copia en cache y a partir ahí se devolverán copias de esos objetos a cada quien lo solicite. Lo interesante de esto, es que el programador, seguirá escribiendo el código de la misma forma que si esta tabla no estuviera en cache. De ese modo, en cualquier momento se puede “promover” una tabla a ReadOnly con la tranquilidad que todo el código existente seguirá funcionando correctamente.
Esto incrementa muchísimo la performance de las aplicaciones, debido a que se pueden obtener objetos complejos que tengan asociaciones a este tipo de objeto, con casi la misma performance que si se trajeran los datos de una sola tabla.

GenerateAsVersionable:
Si se agrega un campo del tipo TimeStamp a una tabla, Cooperator Modeler detectará esto automáticamente y dará la posibilidad de elegir si se quiere manejar concurrencia para esa tabla. Si se elije poner en True esta opción, se generarán los stored procedures de una forma que detecten al momento de actualizar, si otro usuario no lo ha cambiado antes. En ese caso se dispara una excepción que el programador deberá atrapar para manejar esta situación. Aclaramos que esta opción estará solo disponible si en la tabla correspondiente existe un campo TimeStamp. Hay que recordar que marcar una tabla como versionable tendrá un pequeño costo de performance, ya que se tiene que chequear la versión del registro cada vez que se modifica el mismo para poder disparar la excepción correspondiente.

GenerateObject y GenerateEntity:
En la página Artefactos, definimos el concepto de Object y de Entity, si no ha leído ese punto, recomendamos hacerlo antes de continuar.
Cooperator Modeler deja al desarrollador la responsabilidad de seleccionar el tipo de objeto a crear para cada una de sus tablas. Recordemos que las entidades, heredan de Object. Esto es, no puede existir una entidad Order si no existe OrderObject del cual heredar. Como regla general para decidir si se quiere generar una Entidad o un Object podría decirse que si se necesitan agregaciones a un objeto o entidad, debe generar una entidad. Como los Object se mapean 1 a 1 con las tablas, no pueden contener agregaciones. Cuando usted agrega cualquier tipo de agregación a un nodo (ya sea una composición o una asociación), Modeler marca automáticamente como GenerateEntity = True ese nodo.
Si ambos GenerateObject y GenerateEntity están en False, no se generará la entidad, ni los mappers para esa tabla.
Si solo se marca GenerateObject = True, la entidad no se generará para esa tabla y el mapper correspondiente devolverá y recibirá objetos del tipo Object.
Si se marca GenerateEntity = true, GenerateObject se pondrá en True automáticamente y se generaran los mappers de manera que devuelvan y reciban objetos del tipo Entity.
Una entidad puede contener agregaciones del tipo Object o del tipo Entity y eso se define en el nodo de cada agregación y no aquí.

GenerateSPxxxxx:
Todas las opciones que comienzan con GenerateSP… permiten habilitar o deshabilitar las generación de los distintos Stored Procedures que se emiten para cada tabla. Esto da la posibilidad de personalizar un stored procedure y que no se sobrescriba cada vez que se genera el modelo nuevamente.

Name:
Es el nombre original de la tabla y no puede modificarse.

OnCache:
Especifica si se mantendrá en caché o no, los objetos de este tipo.

PrimaryKeyFields:
Tampoco puede modificarse, contiene una colección con los cambios que forman parte de la Primary Key de esa tabla. Es leído por los templates de generación.

Queries:
La herramienta de generación, genera cantidad de consultas automáticamente tomando como base todas las relaciones que hay entre las tablas. Por ejemplo, sin que se tenga que especificar nada, el mapper OrderMapper que sirve para recuperar y grabar órdenes, contiene un método llamado GetByCustomers que devuelve todas las ordenes de un cliente. No hay que hacer nada para que se genere este método, se generará automáticamente ya que se infiere del modelo.
Pero hay otro tipo de consultas, que no pueden inferirse del modelo, como por ejemplo: recuperar todas las órdenes correspondientes a una fecha. Para ese tipo de consultas, existe la colección Queries, que el desarrollador puede crear y guardar en el modelo. Por cada Query que se agregue, se generará un Stored Procedure y un método en el mapper correspondiente. Cuando se elige agregar una nueva Query a la colecciónn aparece una ventana así:

modeler_newquery.jpg

Veamos que significa cada opción dentro de esta ventana.

GenerateQuery:
Permite generar o no la consulta. Existe para poder deshabilitar la generación de la misma sin tener que borrarla del modelo.

Parameters:
Son los parámetros necesarios para el Stored Procedure, si se comete un error cuando se los escribe, se disparará un error en el momento de la generación del mismo.

QueryName:
El nombre de la consulta, en el ejemplo “GetByDate”, hace que se genere un Stored Procedure llamado Orders_GetByDate, y en el mapper llamado OrderMapper se agregará un método denominado GetByDate que invocará a dicho Stored Procedure.

QueryText:
Es la consulta SQL. Apretando el botón expandir (…) se puede editar el texto completo en una nueva ventana. Aqui se puede usar <FIELDS> y <TABLE> para que el generador reemplace automáticamente los campos de la tabla que se necesitan, así como también el nombre de la misma. Esto es particularmente útil si en algún momento se cambian los campos que se desean formen parte de la entidad, no se tiene que cambiar cada stored procedure nuevamente.

ReturnType:
Esta opción sirve para definir qué tipo de datos devuelve la consulta. En el ejemplo, si se sabe que la consulta devuelve un registro, se va a querer que el método devuelva un Order, pero si se sabe que devuelve varios registros, se va a querer que el método devuelva un OrderList.
Además se puede hacer un Stored Procedure que devuelva un Total o una Fecha, etc.. Para eso casos se debe elegir la opción, ReturnScalar.

ScalarCLRType:
Si se ha elegido la opción ReturnScalar en el punto anterior, aquí se debe especificar qué tipo de dato CLR se espera.

Bien, hasta aquí hemos explicado para que sirven y como se usan las opciones para los nodos del tipo Objecto/Entidad, en la siguiente página, vamos a explicar las opciones para nodos del tipo propiedad: Cooperator Modeler (2)

One Comment en “Cooperator Modeler”


  1. […] el proyecto se incluye Cooperator Modeler, una herramienta de modelado y generación de […]


Los comentarios están cerrados.


A %d blogueros les gusta esto: