Consejo para mejorar las capacidades de tu aplicación Powerbuilder empresarial ( I )

Ok, ahora si comenzamos a ver algo de detalle…

Uno de los primeros pasos para crear una aplicación Powerbuilder empresarial de alto rendimiento, escalabilidad y fácil comprensión es la estructuración de las clases base, es decir crear todo el conjunto de librerías base de las cuales se realizaran las herencias que tu aplicación utilizara, para esto hay 2 sugerencias, ambas tiene sus ventajas y desventajas pero dependerá de tu gusto personal para utilizarlas, en orden de recomendación tenemos:

1.- PFC: Son un conjunto de librerías que contienen herencias especializada de los objetos del PB, tiene muchísimas utilidades como calendarios, generadores de SQL, visores entre algunas otras funcionalidades, son bastante estándar, gratuitas solo tienes que descargarte el manual y puedes tener acceso a un pequeño framework bastante útil y completo, la desventaja es que los cambios de versiones de Powerbuilder suelen traerle problemas porque se vienen arrastrando desde versiones 6 y algunas funciones pueden pasar a ser deprecadas de una versión a otra
Mas referencias sobre esto:
http://www.pfcguide.com/index.asp
http://www.wikilearning.com/curso_gratis/powerbuilder_vs_delphi-pfc_powerbuilder_foundation_classes/3856-10
http://www.todoexpertos.com/categorias/tecnologia-e-internet/respuestas/493361/pfc

2.- Librerías Personalizadas: Las librerías personalizadas no es mas que un conjunto de librerías propias de Powerbuilder heredadas y especializadas por ti, por ejemplo w_mdi_base hereda de Windows pero esta totalmente especializada para ser una ventana mdi y a su vez tienes una ventana w_response_base hereda de Windows que es una especifica para hacer ventanas modales. El funcionamiento y características de una ventana mdi son muy diferentes a la de una response, pero viene del mismo origen, esto te asegura que todas las ventanas responses o mdi que uses de ahora en adelante serán idénticas en imagen, solo cambiaran en lo que tu quieras caracterizar cuando las implementes, lo mismo sucede con todos los demás objetos.

Si tomas esta opción de aconsejo que dividas tu aplicación en 7 grupos concretos y sugiero que en el árbol de librerías se orden de esta forma porque mientras mas algo este mas genéricas son y menos acopladas y mientras mas abajo mas especializadas y compuestas por lo tanto mas acopladas, además este orden ayuda al "builder" de Powerbuilder a regenerar y compilar mas rápido

Funciones Genéricas: Esta será una librería creada con el único propósito de almacenar funciones globales genéricas de tu aplicación y que NO TENGAN NADA QUE VER CON EL NEGOCIO, es decir si esa librería la sacas de donde esta y la metes en otra aplicación de la misma versión y te falla entonces esa librería no te sirve. Esta librería tiene cono función almacenar funciones totalmente separadas del negocio como por ejemplo una función que te convierta un string en un array, que te de la fecha de la base de datos de la conexión, una función que reemplace texto o que convierta números a letras

Clases Genéricas: Esta debe contener solo custom nonvisualobject que no dependan de nada y sean reutilizables, por ejemplo una clase que maneje seguridad y encriptación de datos, otra que encapsule el manejo de un Excel o Word, o que pueda enviar y recibir datos por un protocolo especifico, esta solo debería tener dependencia de las funciones genéricas así que si traspasas las librerías genéricas y esta librería a otra aplicación Powerbuilder de la misma versión y falla entonces no te sirve

Objetos Genéricos: En esta librería deberías dejar todas las herencias especializadas y datawindows de los objetos visuales y no visuales que vayas a utilizar Windows, labels, menú, objetos compuestos (userobjects) personalizados genéricos, objetos de transacción personalizados. Con la única librería que debería tener acoplamientos en con la de funciones genéricas y la de objetos genéricos

Funciones Genéricas de Negocio: Aquí deben ir las funciones globales mas genéricas de tu negocio, por ejemplo se me ocurre que el calculo de un impuesto X es usado por muchas opciones de tu sistema, pues que mejor que crear una f_calculaimpuesto(double db_monto_gabable) return double y ahí tenemos una función, lógica, reusable y de fácil manejo y mantenimiento, solo debería tener dependencia de las librerías superiores

Clases Genéricas de Negocio: Aquí es de sugerir que se guarden toda las clases no visuales NVO propios del negocio que sean de uso global por toda la aplicación, esos suelen ser por lo general los NVO que describen a las entidades de base de datos n_cst_impuesto, n_cst_inventario y otras por el particular, ya deberían estar aquí implementando su crear, modificar, modificar forzado, eliminar, eliminar forzado y cargar, esto es muy útil para la comunicación de datos entre entidades y la persistencia de los datos, algo muy parecido a la implementación de lo que hacen los ORM en lenguajes

Objetos Genéricos de Negocio: Aquí debe in contenidos, los datawindows , herencias especializadas y userobjects que son de uso muy muy frecuente en la aplicación, como lo pueden ser listas desplegables específicas de la aplicación, como dimos el ejemplo del impuesto puedes tener un userobject que muestre una lista desplegable de impuestos validos para seleccionar

Librerías de Negocio: Estas librerías deben contener toda la implementación del negocio puntual que se este trabajando, ventanas, objetos súper especializados, datawindows, y todo lo concerniente a ese negocio que se maneje, el orden del resto de librarías sugiero que sea mas abajo mientras mas use funciones, objetos o clases de las otras librerías de negocio