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)