Atributos basados en dominios y variables basadas en atributos (2da. Parte)
En el post anterior, comentaba la importancia de usar dominios con significado, para facilitar la propagación de cambios desde el modelo de datos a los programas.
Otra ventaja de tener bien definidos los dominios, es el de poder agrupar todas las cosas que son de la misma categoría, facilitando la identificación de los objetos que tengo que cambiar.
Por otro lado, al tener tanto variables como atributos con dominios, podemos hacer validaciones mas estrictas de lo que hoy permite Genexus.
Supongamos que tenemos los atributos (*)
MovimientoPeso - Domino PesoKG N(10,2)
CamionPeso - Dominio PesoToneladas N(10,2)
Si en un programa tenemos una operacion que haga una asignacion de
MovimientoPeso = CamionPeso + &Carga
muy posiblemente estemos introduciendo un error, al sumar pesos en diferentes unidades, aunque los ambos sean numéricos.
Lo mismo sucede si pasamos de variables que tienen mas decimales a otra que tenga menos decimales, podemos estar perdiendo precisión cuando guardamos los resultados en la base de datos.
También puede dar problemas cuando se asigna un string mayor en uno menor. Mientras se maneja en variables, no hay problemas, pero al guardarse en la base de datos, puede ocasionar cancelaciones.
Esto puede verificarse, haciendo una análisis estático de código, con el KBDoctor, y en la próxima versión tendremos controles para asignaciones, comparaciones y llamadas entre programas.
La idea básica es controlar que las operaciones sean compatibles en el tipo de datos (esto hoy ya lo controla GeneXus) y agregar controles, donde avise cuando NO COINCIDEN EL NOMBRE DE LOS DOMINIOS, en las asignaciones, condiciones y llamadas entre objetos. Nos ha permitido encontrar algunos errores difíciles de detectar por otros medios.
Otra ventaja de tener bien definidos los dominios, es el de poder agrupar todas las cosas que son de la misma categoría, facilitando la identificación de los objetos que tengo que cambiar.
Por otro lado, al tener tanto variables como atributos con dominios, podemos hacer validaciones mas estrictas de lo que hoy permite Genexus.
Supongamos que tenemos los atributos (*)
MovimientoPeso - Domino PesoKG N(10,2)
CamionPeso - Dominio PesoToneladas N(10,2)
Si en un programa tenemos una operacion que haga una asignacion de
MovimientoPeso = CamionPeso + &Carga
muy posiblemente estemos introduciendo un error, al sumar pesos en diferentes unidades, aunque los ambos sean numéricos.
Lo mismo sucede si pasamos de variables que tienen mas decimales a otra que tenga menos decimales, podemos estar perdiendo precisión cuando guardamos los resultados en la base de datos.
También puede dar problemas cuando se asigna un string mayor en uno menor. Mientras se maneja en variables, no hay problemas, pero al guardarse en la base de datos, puede ocasionar cancelaciones.
Esto puede verificarse, haciendo una análisis estático de código, con el KBDoctor, y en la próxima versión tendremos controles para asignaciones, comparaciones y llamadas entre programas.
La idea básica es controlar que las operaciones sean compatibles en el tipo de datos (esto hoy ya lo controla GeneXus) y agregar controles, donde avise cuando NO COINCIDEN EL NOMBRE DE LOS DOMINIOS, en las asignaciones, condiciones y llamadas entre objetos. Nos ha permitido encontrar algunos errores difíciles de detectar por otros medios.
Algo que se precisa son dominios estructurados. Así CamionPeso lo definis como el dominio Medida y el dominio es en realidad una pareja Valor N10,2 y Unidad C3
ResponderBorrarLuego eso, en la base se generaría como dos atributos, CamionPesoValor y CamionPesoUnidad.
Asi , la operación "+" de los numéricos dejaría de tener sentido. Simplemente no compila un MovimientoPeso = CamionPeso + &Carga y estarías obligado a implementar una función
MovimientoPeso = SumaMedida(CamionPeso , &Carga)
donde resolves el conflicto de sumar dos unidades de medida diferente
Seria muy buen poder tener dominios estructurados, pero por el momento, no parece estar dentro de las proridades.
ResponderBorrarTener un dominio Direccion = {Calle, Nro, Adicional, Ciudad, Pais, CodigoPostal}
podria estar muy bueno.
Se puede tener un Atributo ClienteDireccion, basado en el dominio Direccion y al leerlo de la base de datos, lo dejara cargado en un SDT ClienteDireccion y accedemos a los campos como
ClienteDireccion.Calle , para solo el valor de la calle.
Simplificaria mucho el modelado.