Aplicaciones Genexus que duren muchos años
Al hacer una aplicación, no es trivial darse cuenta si la misma va a persistir muchos años o va a ser sustituida en poco tiempo.
Si se piensa tener una aplicación que dure mucho, conviene tomar algunas precauciones para que sea mas fácil su transición tecnológica.
En un esquema básico de los diferentes componentes de la aplicación tenemos
La interfaz de usuario (listados, formularios, paneles) son los que a lo largo de los años han sufrido cambios mas profundos y han necesitado mas reprogramaciones. Las pantallas de caracteres, luego los winforms, después los webforms y ahora los paneles de SD. Estos son cambios provocados por cambios tecnológicos que han implicado cambios en nuestras aplicaciones.
En la capa de lógica de negocio, hay muchos cambios provocado por cambios en la forma de trabajar (por ejemplo antes se necesitaban muchos listados y ahora no) y cambios en la forma de hacer los negocios. Cada vez es menor el ingreso de datos por partes de los usuarios y los datos se sacan de servicios u otros dispositivos. Esta capa sufre mas cambio por la forma de hacer negocios.
El modelo de datos, es la capa mas estable de las tres, aunque han aparecido muchas formas nuevas de almacenar información (nuevos tipos de bases de datos). Las bases de datos relacionales, son las que tienen una base teórica mas potente y han prevalecido pues han sido las que mejor se adaptan a la forma de hacer negocios.
Es importante tener en cuenta, que los datos de hoy, van a generar los programas del futuro a traves de inteligencia artificial, por lo que es importante trabajar en tener el mejor modelo de datos posible, con la mejor calidad de datos posibles, para tener menos errores y que la aplicación pueda funcionar por muchos años.
Entonces, los consejos para tener una aplicación que duren muchos años, serian:
- Programar la interfaz de usuario, en forma independiente a la logica de negocio
- La logica de negocio, debe ser lo mas adaptable a la forma de hacer el negocio actual. Hay que mantenerla actualizada y modernizarla (usar nuevos objetos, sacar warnings, sacar deprecated, etc)
- Trabajar en el modelo de datos, para que refleje lo mejor posible la realidad, con integridad referencial y validando la calidad de los datos que se ingresan
Son cosas que todos sabemos que son buenas, pero que exigen un esfuerzo para cumplirlas.
UPDATE:
Me hicieron una pregunta que resulta interesante.
Porque cambian con mas frecuencia la interfaz de usuario que el resto de los componentes del sistema?
La interfaz de usuario, se ve influenciada por al menos los siguientes factores:
* Dispositivo de acceso a la aplicación
No es lo mismo acceder a una aplicación con un teléfono con pantalla de 4 pulgadas a hacerlo con un monitor de 40 pulgadas.
* Sistema Operativo de acceso
Acceder con iOS / Android / Windows / Linux / etc a veces exige cambios para que se vean correctamente.
* Navegadores WEB
Los cambios en los browser usados para navegar aplicaciones web, muchas veces afectan la programación y la forma de mostrar la interfaz del usuario.
* Bibliotecas de Interfaz de Usuario.
En aplicaciones WEB, aparece una biblioteca javascript cada pocos meses y su adopción es muy rápida en el mercado. Adoptar una biblioteca de estas, implica una reescritura de toda la interfaz.
La logica de negocio, cambia por los cambios en la forma de hacer negocios, que es cambiante, pero a menor ritmo que el la interfaz de usuario.
El modelo de datos, es mas estable aun, pues se llego a un consenso para el acceso a las base de datos relacionales con SQL y ha tenido una estabilidad muy alta. Por eso el mismo modelo de datos puede ser accedido desde diferente versiones de la misma aplicación sin tener que hacer cambios en la misma.
es inviable usar este modelo, aun que suena bueno, ya me toco participar en un proyecto así y usando GeneXus, pierdes toda la potencia de GeneXus, si usaba esto, pues, la idea en la kb es no tener el modelo y al momento de generar las interfaces, lo debes hacer de cero y a mano. tanto gx como sus patterns necesitar tener el modelo de datos y para hacer bien este modelo, se deben tener los componentes separados.
ResponderBorrarEn el artículo, no digo que se necesite desarrollar la aplicacion en tres capas (instalando cada capa en una maquina diferente) sino que se puede aplicar los consejos con una aplicacion monolitica.
BorrarAlcanza con :
* NO poner logica de negocio en los eventos de las transacciones o panels.
* Borrar lo que no se usa (tablas, variables, objetos, eventos, etc)
* Eliminar Warning / Deprecated
* Actualizar la base de datos con BC y no con procedures
* Definir el modelo de datos con dominios y todas las referencias de integridad
* Manejo consistente de NULL en la base de datos.
Y por otro lado, si bien hacer modelos en tres capas es complejo, se puede hacer con GeneXus. En los próximos meses habrán herramientas para hacer esto en forma mas automatica.