Modulos GeneXus: Que les falta para que sean (mas) utiles?
La funcionalidad de los módulos en GeneXus es un desarrollo que tuvo un impulso inicial, y luego se estancó un poco, pues han surgido muchas otras cosas que han ocupado la agenda de desarrollo.
Hace mas de un año escribí un articulo sobre el tema, y ahora voy a reforzar un poco la idea, pues sigo necesitando cosas de los módulos.
Como veo estratégicos el tener un buen sistema de módulos, creo que vale la pena retomar y ampliar su funcionalidad para lograr manejar mejor nuestros desarrollos.
El hacer que se extienda mas el uso de módulos, va a lograr mejorar los tiempos de build all y con eso también la productividad de quienes desarrollamos con Genexus.
Si llegamos a tener módulos distribuibles en forma de binarios de forma facil y controlada, vamos tambien a estar mejor parados para arquitecturas interesantes como la de microservicios.
Los puntos que a mi mas me duelen cuando uso módulos son:
1) Tablas publicas o privadas.
Me gustaria poder tener independencia entre la visibilidad de la tablas y de las transacciones que las generan.
En desarrollos web, es común querer tener un transacción publica, pero dejar la tabla privada, como para impedir que desde afuera del modulo puedan hacer un for each sobre la tabla.
2) Tratar la integridad referencial como un acceso diferente.
Como esta definido ahora, si tengo una tabla cuya clave es clave foránea de una tabla de otro modulo, hay que definirla como publica.
Ya estoy pidiendo mucho y no me meti aun con la posibilidad de empaquetar modulos..
Hace mas de un año escribí un articulo sobre el tema, y ahora voy a reforzar un poco la idea, pues sigo necesitando cosas de los módulos.
Como veo estratégicos el tener un buen sistema de módulos, creo que vale la pena retomar y ampliar su funcionalidad para lograr manejar mejor nuestros desarrollos.
El hacer que se extienda mas el uso de módulos, va a lograr mejorar los tiempos de build all y con eso también la productividad de quienes desarrollamos con Genexus.
Si llegamos a tener módulos distribuibles en forma de binarios de forma facil y controlada, vamos tambien a estar mejor parados para arquitecturas interesantes como la de microservicios.
Los puntos que a mi mas me duelen cuando uso módulos son:
1) Tablas publicas o privadas.
Me gustaria poder tener independencia entre la visibilidad de la tablas y de las transacciones que las generan.
En desarrollos web, es común querer tener un transacción publica, pero dejar la tabla privada, como para impedir que desde afuera del modulo puedan hacer un for each sobre la tabla.
2) Tratar la integridad referencial como un acceso diferente.
Como esta definido ahora, si tengo una tabla cuya clave es clave foránea de una tabla de otro modulo, hay que definirla como publica.
Pongamos por ejemplo, la tabla de Monedas y la quiero mantener privada, para que nadie desde afuera del modulo que mantiene los datos haga for each en forma directa.
Va a ser muy común y bueno que otras tablas hagan referencia a monedas, pero solo para hacer joins y chequeo de integridad referencial, pero para nada mas.
O sea, quiero que se siga definiendo un campo MonedaId en las tablas fuera del modulo, pero que si alguien necesita hacer:
for each
Where MonedaId=&MonedaId
&MonedaSimbolo = MonedaSimbolo
endfor
lo haga llamando a un procedure de monedas y no lo pueda hacer directamente en el objeto fuera del modulo.
Hoy, con solo tener la integridad referencial haca afuera del modulo, ya posibilida hacer el for each de arriba.
3) Codigo de chequeo de integridad referencial en trasacciones llamando procedures.
Estaria bueno que el chequeo de integridad que hoy se hace dentro de las transacciones, se hagan en procedures que están en el mismo modulo que la tabla referenciada.
Ej:
Transacción Facturas referencia Monedas
En la transacción de Monedas, en la parte de insert y delete, hay chequeos que acceden a la tabla de Facturas para ver si el valor insertado es una moneda valida o si existe una factura con un código de moneda que impida que se lo borre.
Todo el código que realiza estos chequeos se generan en forma monolítica en las transacción.
Tal vez podrían generarse mas objetos (procedures o data providers) para hacer este chequeo y se podrían generar en el mismo modulo que la tabla.
4) Poder generar los objetos de un modulo y quienes lo referencian.
Tener una forma facil de especificar y generar los objetos de un módulo y quienes lo referencian.
Es muy util y necesario cuando se estan haciendo re-modularizaciones.
5) Performance de diagramas de módulos.
Los diagramas de módulos demoran muchísimo en KB que tienen muchos objetos y se vuelven inusables. Seria bueno poder mejorar la performance.
6) Agregar Tablas a la vista de interfaces
Hoy muestra las transacciones y los SDT, pero no las tablas, con lo cual no se ve todo lo que expone el modulo.
7) Ver los objetos públicos.
En el editor de codigo, seria bueno poder ver de forma mas facil los objetos públicos de otro modulo.
Por ejemplo, si en editor pongo
Moneda y un punto, y tengo un modulo moneda que muestre aquellos objetos públicos (y solo los públicos) de dicho modulo.
8) Dynamic Combo Box
Hoy los dynamic ComboBox tiene dos posibilidades para ser cargados, con atributos y con Data Provider.
A mi me gustaria poder especificar solo los atributos, pero que funcione como Data Provider, o que genere automáticamente el Data Provider en el modulo donde esta la tabla, y que lo utilice, sin tener que programarlo en forma manual.
Ya estoy pidiendo mucho y no me meti aun con la posibilidad de empaquetar modulos..
Yo estoy sufriendo con el tema del empaquetado de modulos. Estoy forzando el uso ya que tengo una kb que Referencia a mis modulos pero me esta costando mucho mantenerlo. El tema de poder distribuir como binario es fundamental.
ResponderBorrarUna que sería de mucha utilidad es tener data Store por módulo y poder empaquetar módulos que tienen transacciones
ResponderBorrarSi, eso seria muy bueno, si pudieramos reorganizar data stores que no fueran el primario.
BorrarFacilitaria muchisimo la puesta en produccion.
Ademas podriams tener data store en diferentes DBMS en los diferentes stores y ahorraria muchisimo tiempo de integracion.
Creo que esta forma de trabajar no esta en los planes (que no conozco mucho).
Lo que si creo que esta en los planes de GeneXus es tener diferentes KB cada una con su modulo y que puedas hacer un deploy de binarios.
Este blog ha sido eliminado por un administrador de blog.
ResponderBorrar