¿Qué es?
Sin duda una de las 3 características más importantes de la plataforma Velneo.
Se trata de un automatismo del editor integrado vDevelop que automáticamente se encarga de refrescar el cambio de identificador de cualquier objeto allí donde se use.
Un ejemplo
Para aclarar mejor la explicación vamos a poner un ejemplo. Imagina que creamos un formulario para editar clientes y le ponemos de identificador CLIENTES, ese formulario lo utilizamos en la propiedad formulario de alta, baja y modificación de la rejilla de clientes.
Unas semanas más tarde decidimos usar abreviaturas para reducir los identificadores y cambiamos el identifcador del formulario CLIENTES por CLT. Es posible que en otros lenguajes de programación o herramientas de desarrollo tengas que manualmente buscar donde se usaba ese formulario y cambiarlo. En Velneo no es necesario, porque cuando cambia un identificador el editor busca donde es usado y realiza el cambio por nosotros. ¿Cómodo verdad?
El ejemplo que hemos puesto es muy sencillo, sin embargo, la potencia de la refactorización es enorme ya que no se limita a objetos, también se refactorizan los cambios de subobjetos sin límite de niveles. Esto significa, por ejemplo, que si cambiamos el nombre del identificador de un control de edición en un formulario y ese identificador es usado en múltiples códigos no hay problema, porque al cambiar el identificador se cambia en todos los sitios, y todos significa “todos” los objetos, subobjetos de Velneo.
Seguridad y productividad
Te preguntarás ¿Qué me aporta la refactorización en Velneo?
- En primer lugar seguridad. Porque si esa refactorización no fuese automática y tuviésemos que hacer esos cambios nosotros manualmente es muy factible que nos quede algún sitio por cambiar. Es cierto que nuestro ejemplo era muy sencillo, pero cuando una aplicación tiene miles de objetos cambiar los identificadores puede convertirse en un acto de valentía o incluso temeridad.
- En segundo lugar productividad. Porque cuando tienes miles de objetos poder cambiar el identificador y que se refresque en todos los sitios donde se usa en un segundo no tiene precio.
Seguridad y productividad son las palabras clave para poder ofrecer servicios de mantenimiento rentables.
La integración de base de datos es clave
Otra de las características diferenciales de Velneo en la integración total de su base de datos con los objetos visuales.
En Velneo todo son objetos, los subobjetos también lo son y por lo tanto de igual manera que un formulario es un objeto también son objetos las tablas, campos, índices, etc. Eso significa que si cambio el nombre de un campo que es usado en cientos de sitios lo puedo hacer con total confianza porque toda la aplicación seguirá funcionando correctamente.
Pero… y los datos
Está claro que al aplicación funcionará perfectamente, pero las tablas que ya están en producción y tienen miles o millones de registros con datos ¿Qué pasa si cambio el nombre a un campo?
Si no haces nada, los datos de ese campo se perderían ya que al detectarse el cambio de estructura en la tabla se regenerará. Al regenerarse la tabla de datos actual se renombra a OLD y se crea una tabla vacía. A continuación se traspasn todos los datos de los campos que existen tanto en OLD como en la nueva creada, por ese motivo no se traspasarían los datos al nuevo identificador.
Sin embargo, eso no es ningún problema porque simplemente declarando un subobjeto a la tabla denominado Traspaso de campo en el que le damos 2 datos el identificador viejo y el nuevo, Velneo automáticamente se encargará al regenerar la tabla de traspasar los datos del campo con identificador viejo al campo con identificador nuevo.
¿Es recomendable cambiar identificadores?
Lo recomendable es programar los objetos con el identificador correcto desde el momento en que los creamos. Sin embargo, la experiencia demuestra que en las fases iniciales de desarrollo y con el paso de los años, las aplicaciones evolucionan y se hace necesario hacer cambios.
Si la herramienta no tiene este sistema de refactorización es normal que el programador tienda a no hacer cambios en identificadores para no generar incidencias.
Pero cuando trabajas con una herramienta que te lo permite sí tiene sentido dejar bien los identificadores para evitar tener objetos o campos cuyo identificador no tiene nada que ver con los datos que contiene.
Deja una respuesta