Metadatos, Parametros y Conocimiento
Desde hace un tiempo, se ha planteado dentro del grupo de desarrollo de Concepto, una discusión amistosa sobre las ventajas y desventajas de las diversas formas de modelar los parametros de una aplicación.
Las diferentes opciones que hemos utilizado a lo largo del tiempo, estan planteadas en esta pagina del wiki de la comunidad
Entre las representacion planteadas, se tiene la de una transaccion con un unico registro y la de la utilizacion de metadatos.
Algunos otros elementos que hemos tomado en cuenta para el intercambio de ideas son:
Aun no tenemos una respuesta definitiva y vamos a seguir debatiendo. Yo estoy bastante inclinado por la transaccion de un unico registro.
Generalizando un poquito - como representar conocimiento
Al articulo del wiki, creo que le falta una componente importante, que es la de como se representa el conocimiento de cuando (o en que objetos) se utiliza ese parametro. Ese conocimiento es util en el momento que necesito medir el impacto que pueda tener cambiar el valor de dicho parametro o cambiar el tipo de datos del mismo.
En el caso de la utlizacion de Transacciones de un unico registro, con un la funcionalidad de Cross Reference en Genexus, se puede ver en que objetos se utiliza. Con los Metadatos, esta funcionalidad queda bastante mas oculta y hay que utilizar algun tipo de busqueda en el codigo para encontrar donde se utiliza.
Algunos otros elementos que hemos tomado en cuenta para el intercambio de ideas son:
- Facilidad de instalacion (para instalar debo correr una reorg + ejecutar una transaccion o un script)
- Facilidad de mantenimiento (saber donde se usa, que impacta si lo cambio)
- Tolerancia a fallos (si instalo algo que usa un parametro, con metadatos en mas tolerante a que no exista, en cambio si no existe el atributo en la base, el programa cancela).
- Performance
- Parametros por Idioma/Usuario/Sucursal
- Jerarquia de Parametros (por ejemplo, hay un valor default, y luego se tiene un valor por usuario, si no existe el del usuario, se toma el general).
Generalizando un poquito - como representar conocimiento
Al articulo del wiki, creo que le falta una componente importante, que es la de como se representa el conocimiento de cuando (o en que objetos) se utiliza ese parametro. Ese conocimiento es util en el momento que necesito medir el impacto que pueda tener cambiar el valor de dicho parametro o cambiar el tipo de datos del mismo.
En el caso de la utlizacion de Transacciones de un unico registro, con un la funcionalidad de Cross Reference en Genexus, se puede ver en que objetos se utiliza. Con los Metadatos, esta funcionalidad queda bastante mas oculta y hay que utilizar algun tipo de busqueda en el codigo para encontrar donde se utiliza.
Cual elegir?
Esto me lleva a la discusion mas general, si el conocimiento debe ser representado como metadata en la base de datos (para ser usado en runtime) o representarlo en la KB (para ser usado en el momento de generacion).
Generalmente, llegamos a la misma conclusión, es bueno que esté en los dos lados !!
Una posibilidad es representar las cosas en la KB y generar la metadata desde la KB, como se hace con GXPlorer o GXFlow. Si esta solucion es posible es la mejor.
La otra opcion que hemos usado en algunos casos es la inversa, o sea cargar la metadata en la KB. Por ejemplo, si tenemos un sistema de menues que realiza calls dinamicos, se pueden generar objetos "dummy" que tengan esos call como estaticos y de esta forma poder usar el Call Browser para ver de donde se llaman los mismos.
Es bueno pensar formas de extraer conocimiento de las KB para tenerlo disponible en runtime, y si es necesario tener metadata creada por nosotros, tambien es bueno pensar la forma de poder incorporarla a nuestras kb.
Esto me lleva a la discusion mas general, si el conocimiento debe ser representado como metadata en la base de datos (para ser usado en runtime) o representarlo en la KB (para ser usado en el momento de generacion).
Generalmente, llegamos a la misma conclusión, es bueno que esté en los dos lados !!
Una posibilidad es representar las cosas en la KB y generar la metadata desde la KB, como se hace con GXPlorer o GXFlow. Si esta solucion es posible es la mejor.
La otra opcion que hemos usado en algunos casos es la inversa, o sea cargar la metadata en la KB. Por ejemplo, si tenemos un sistema de menues que realiza calls dinamicos, se pueden generar objetos "dummy" que tengan esos call como estaticos y de esta forma poder usar el Call Browser para ver de donde se llaman los mismos.
Es bueno pensar formas de extraer conocimiento de las KB para tenerlo disponible en runtime, y si es necesario tener metadata creada por nosotros, tambien es bueno pensar la forma de poder incorporarla a nuestras kb.
Comentarios
Publicar un comentario
1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.