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

Arquitectura MVC sobre aplicaciones Powerbuilder empresariales

La arquitectura de desarrollo MVC como lo saben y me voy a dar el tiempo de resumir, es poder separar en 3 capas lógicas una aplicación, La Vista que es lo que inter actual con el usuario y su función principal es poder llevar información al usuario, y tomar capturar datos que luego serán enviados a la capa lógica denominado el Controlador, esta capa es la que tiene la obligación de implementar el negocio que se quiere desarrollar y se vale de la capa lógica denominada el Modelo para persistir datos y extraerlos de una fuente de datos.

En PB tenemos todos los estos componentes y los explico a continuación:
La vista: contamos con los objetos windows, userobject, menu, singlelinetext, statictext, datawindows object, datawindows, multilineedit, editmask y en general de todos los objetos considerados visuales, además de funciones que prestan servicios visuales o de interacción con el usuario como son los messagebox y las funciones para invocar las common dialogue
El controlador: nonvisualobject(NVO) personalizados (es la base de todo), el datawindows, datastore, los proxys y en general todos los objetos considerados no visuales, a excepción del transacción object
El modelo: en este caso solo podría nombrar al transaction object que es el único objeto que negocio con la unidad de almacenamiento

Los objetos en las 3 capas inter actúan, hay que saber separar cuando u proceso es de vista, de controlador o de modelo para poder comenzar a trabajar, uno de los vicios de la programación visual es la de desarrollar procesos propios de una capa logia en otra, como pro ejemplo y es muy común ver, que se tenga en proceso de recálcalo de un inventario en un botón o que un NVO lance un mensaje por pantalla, llamar a una función global para reajustar las posiciones de una ventana especifica, hacer que un código dentro de la ventana que busque información en otra ventana. Este tipos de practicas a la cual considero un vicio con nombre y todo ("Programación orientada a botones") no niego que sea una solución perfectamente rápida, lo es, pero como todo vicio trae consecuencias perjudiciales como lo son el aumento del acoplamiento de la aplicación, la dificultad de escalamiento, reduce entendimiento del código y lo peor de todo, impide la reusabilidad de la funcionalidad. Es por esto que hay que estar bien claros en que procesos son de vista, cuales los de controlador y en cuanto a las de modelo no existen tantos problemas porque el Powerbuilder se implementan por un mismo canal que es el objeto de transacción

El datawindows lo considero el mas peligroso de los vicios, porque presenta las 3 capas en si mismo, tiene la vista que presenta los datos y permite editarlos, se le pueden agregar comportamientos y reglas de negocio o incrustárselas en tiempo de ejecución y además permite persistir... es muy importante hacer diferencia de cuando es necesario crear un datawindows que presente datos, un datawindows para obtener datos, un datawindows para usarse como un recordset y cuando lo utilizaremos para persistir pero no recomiendo en ninguno de los caos hacer uso de los 3 usos sobre un mismo DW, ya que este no permite por lo menos heredar para especializar sus funciones y por mi misma experiencia he tenido que desvirtuar DW o crear muchos iguales porque mi aplicación creció y lo que necesito ver en pantalla no es necesariamente la misma estructura que necesito como estructura de datos

En el proximo post dare unos ejemplos de como seria una buena practica de desarrollo MVC que sea lo suficientemente escalable y lo suficientemente sencilla como para poder hacer aplicaciones rapidas y a la vez reutilizables

Powerbuilder es ORIENTADO A OBJETOS pero el datawindow NO!!

Este título puede parecer redundante para los que ya conocen la herramienta, para los que no la conocen entoces se los informo.

La esencia del Powerbuilder es generar aplicaciones portables (gracias a la maquina virtual de Powerbuilder), con un desarrollo orientado a objetos, con interfaces graficas predefinidas que nos ayudan a ahorrar tiempo en el trabajo mas laborioso de hacer un sistema como lo es la creación de interfaces con el usuario. Aunque tal vez hay cosas que ha tenido que ir mejorando en cuanto a su orientación a objetos, nótese que se comenzaron a usar los constructores con parámetros ya después de la versión 11, obligados por la integración con .net, pero aun así te permite usar todos los beneficios comunes de la POO, polimorfismo, encapsulamiento, ocultación, etc.

Para los nuevos programadores se les puede hacer común a Microsoft visual basic, es digamos la herramienta mas parecía, pero no iguala nunca su poder y capacidades, de hecho los que han trabajado VB en las universidades y por su cuenta suelen venir con vicios de programación que generan malas practicas sobre PB estas las explicare en otro post.

El Datawindows, es una tecnología de Sybase, de verdad muy útil y tan útil y permisiva que facilita las malas practicas con el, una desventaja que me parece es que no es orientada a objetos, es una tecnología que contiene todo el modelo MVC dentro de si por lo que regularmente se de delega todo el trabajo, para cosas sencillas y de poca escalabilidad es optimo encargarle el trabajo de mostrar data, modificar campos, validarlos, y nuevamente persistirlos, pero cuando se van a procesos mas complicados y de escalabilidad constante comienza a verse las desventajas, como del de tener millones de DW iguales, o verse obligados a modificarlos en tiempo de ejecución para que contenga comportamientos requeridos por el negocio que se este desarrollando. Como les digo es una excelente herramienta pero hay que usarla sabiamente


El hecho de que es necesario incrustar el datawindows en un datawindows object para poder implementar sus métodos lo que nos lleva a la conclusión de que el DWO es una interfaz que encapsula al DW, por lo tanto su integración no es directa, aun así trabajan muy bien las 2 tecnologías juntas, pero hay que estar claro que son 2 tecnologías diferentes interactuado por lo que el desarrollo debe siempre tener en cuenta estas premisas.

FAQ: ¿Que me puede dar este blog que yo necesite?

Para todos nosotros que trabajamos en Powerbuilder no es de sorprender que no se consiga documentación adecuada sobre como resolver problemas con la herramienta... si bien existe poca documentación de la materia existe aun menos documentación sobre como hacer hilos de ejecución, consumo de Web service, implementación de apis, integración con tecnologías abiertas y si creen que eso es difícil de encontrar, pues encofrarlas en español es todavía mas difícil ( en español como idioma materno siempre es mas fácil comprender las cosas ) estas o tras razones me llevaron a crear este blog, que trata de servir como ayuda a los programadores PB, tal vez existan unos cuantos mas blogs como este pero quiero poder llevar mi conocimiento de 5 años de experiencia, en aplicaciones Powerbuilder de alto rendimiento y elevada criticidad sumado con mi conocimiento de patrones de diseño, arquitecturas oo y soa, Oracle, conexiones a Internet, java y php para transmitirles lo que pueda, mis criticas, opiniones y códigos, que para estos pocos años, he ido recolectado... y para exponer mi criterio sobre una buena practica sobre las aplicaciones desarrolladas en Powerbuilder


Expondré todo en la base de Powerbuilder 10.5 que me parece una versión estable y que se adapta mas a lo que necesito explicar... los adelantos en powerbuilder 11 en adelante no los manejo... pero eso en resumen es sencillamente ajustes a las interfases visuales de la herramienta, ajustes a algunas conexiones con Web services, un ajuste a las tecnologías datawindows y en general una casi total implementación de .net (de hecho cada vez parece mas un editor de .net)