Formulario Dinámico vs Formulario en Diseño?
 

Hola a Todos.

Quiero saber sus comentarios de los amigos con experiencia del foro.

Mi consulta se origina por la necesidad de construir un aplicativo y este tendría un aproximado de 300 Transacciones (Formularios) diferentes diseños y de varios eventos similares.

Hay 2 alternativas:

1. Hacer el diseño de los 300 transacciones en cada formulario que corresponde.
2. Elaborar tablas en base datos y que ahí se definan las transacciones y los componentes y crearlos de forma dinámica en memoria.

Las preguntas son las siguientes:

1. Cual es la mejor alternativa? que recomiendan o existe otra forma de manejar un aplicativo nuevo.
2. Implementado ambas alternativas cual seria la mas optima con respecto su funcionalidad? quien consume mas memoria? quien es mas rápido su performance en ambiente producción?
3. El tener un proyecto con muchos formularios es una desventaja vs la creación de formularios dinámicos en memoria? para su mantenimiento? cual es mas riesgoso o inseguro en sus implementacion?

Me gustaría saber sus comentarios a las personas que hayan pasado por este tipo de experiencias y a gurus de la herramienta. Capaz hay ejemplos o información de otras alternativas para manejar un aplicativo con esta cantidad de transacciones.

Muchas Gracias por sus comentarios ^\||/

La verdad es que nunca he escuhado el érmino transacción como sinónimo de formulario ni sé a qué te refieres con eventos.

Sin embargo, en términos muy genéricos puedo comentarte que hacer una aplicación con 300 formularios no tiene ningún problema salvo que cargues todos al mismo tiempo. O sea que, más que construirlos dinámicamente, lo que tienes que hacer es crearlos en la ejecución en el momento que los necesites y destruirlos en cuanto los cierres o dejes de usarlos.

¿Crear un formulario dinámicamente a partir de información guardada en una base de datos? Pues es que ni siquiera se me ocurre qué es lo que guardarías. Un formulario consta no sólo de componentes sino también de métodos y, la información de las componentes, a fin de cuenas, es lo que se guarda en el archivo DFM del formulario y como recurso en el ejecutable así que sólo estarías cambiando de lugar el almacenaje con la desventaja de perder el poder de la VCL para leer e instanciar los componentes.

En fin, creo que deberías contextualizar más tu problema para poder dar una mejor orientación.

LineComment Saludos

Hola roman,

Cuando me refería a transacciones en realidad me refería a formularios con componentes y sus eventos. muchos de los formularios comparten los eventos del mismo formulario y/o de los componentes hijos del formulario.

Con respecto a una Aplicación con formularios dinámicos, ahí viene mi duda ya que he visto un aplicativo que lo esta manejando así en base datos. Quiero saber que ventajas habían en implementarlo así? mas rápido el aplicativo? menos consumo de Memoria? Al hacer un *.exe mas pequeño es mas rápido su respuesta.

Nota: Este aplicativo esta diseñado para que los usuarios no hagan uso del Mouse. no se si por ello la desicion de hacerlo dinámico.

Gracias por tus comentarios y espero haber sido mas claro en mi inquietud.

Saludos.

Creo que estás más liado que un plato de espaguetis :D

Define lo más exactamente posible lo que quieres conseguir, me refiero a algo así como: "Necesito realizar un programa para controlar los coches que pasan por una calle teniendo la posibilidad de mostrar estadísticas gráficas según su color, marca y número de pasajeros".

Bueno para dar mas detalle y motivo de mi consulta.

Estoy viendo un aplicativo que esta hecho en D6 y este esta implementado para manejar aprox de 300 a N formularios de forma dinámica.
toda la configuración de los atributos y componentes esta en tablas de BD lo interesante que cada formulario maneja sus atributos y toda la información ingresada se registra en una sola tabla(los atributos de forma vertical asociados a su valor) la idea que creo que el motivo es por que no quisieron crear 1 tabla x formulario ó una super tabla para almacenar la data de todo los formularios.

Mi pregunta partía si esta solución es la optima?
Si el hacer todo dinámico tiene sus consecuencias que afecte el performance del aplicativo.

Espero ahora me comprendan mejor el por que de mi pregunta.

Depende de lo que necesites hacer, pero no podemos saberlo porque no has contestado a mi pregunta.

Sobre esto, ya que he participado en proyectos con ideas similares.

El que afecte o no el desempeño es difícil de predecir. Se *supone* que estatico es mas rapido que dinamico, asumiendo un compilador eficiente.

Sin embargo, un interprete eficiente puede tener ventajas sobre el compilador si aprovecha la información de su entorno y se optimiza de forma correcta.

HEY, COMO ASI "COMPILADOR" e "INTERPRETE"? No que estamos hablando de formularios?

Es porque efectivamente, en nucleo, lo que hablas es un interprete de formularios. Y lo que hace Delphi al guardar en .DFM/.PAS es compilar. O mas exactamente, *serializa* el formulario en .DFM y guarda parte compilada en .PAS.

Lo que tu dices es *serializar* en tablas.

------

En resumen? Eso como dices funciona. De hecho funciona tan bien que asi *exactamente* es como estaban implementados los formularios de FoxPro. Literalmente guardados en tablas. Solo que no todo en una sola!.

Una cosa importante: La estructura de esas tablas es crucial, y deben estar optimizadas para interpretarse/deserializarse de forma *rapida*.


-------
En lenguajes con creadores de formularios mediocres como TODOS menos Delphi, FoxPro y Acces; hacer formularios "por codigo" y utilizando algun medio implicito (el mismo codigo) o explicito (JSON, tablas, arboles) de serializar esos formularios es lo COMUN.

Yo he hecho eso muchas veces. Y la verdad preferiria en la mayoria de los casos no tener que. Solo es razonable si:

- Estoy haciendo un IDE
- Estoy haciendo un ERP muy complejo
- Estoy haciendo cualquier programa que requiera crear formularios de parte de terceros, como un IDE, o un ERP, un game engine,....

O

- Estoy haciendo paginas web o usando objective-c o java, o C#... o mejor dicho, es casi que obligado en casi todos los lenguajes mediocres para hacer UIs.

Lo segundo mejor es que el lenguaje tenga una buena API que haga facil crear UIs, como REACT en JS o REBOL. Pero eso se cuenta con los dedos...
-------

La parte preocupante, que Casimiro tambien noto, es que no parece que tengas claro el porque REALMENTE quieres algo asi.

Y aun MAS PREOCUPANTE es porque quieres 300 formularios? Que usuario quiere manejar tantos. Porque hay tantos? Por que?

Eso es una indicacion de un software inmensamente complejo y grande (como un ERP o un sistema operativo).

Seria muy util que reduzcas al maximo ese numero, y hagas un estudio referente a la UX (experiencia de usuario).

Hola mancx,
Quiero primero agradecerte por tu tiempo y por la información compartida. mas claro que el agua lo que comentas.

El motivo que me a llevado a realizar esta pregunta al foro es por que es un caso real de un sistema que estoy revisando. y la estructura esta diseñada de esa manera. al menos en las pantallas que son transaccionales.

Para que lo vean mas claro es un sistema que lo usan los cajeros de un financiera. ellos le llaman transacciones a cada operación que hace el usuario en la financiera. Si mencione que son 300 formularios era por que ellos cada transacción tiene un input diferente de la información y por ello han definido en tablas el diseño de esas transacciones.

Es mas la data se guarda de forma vertical, osea las filas son los atributos y hay una columna que guarda el valor de la transacción.

Lo que se quiere hacer es migrar ese aplicativo a una versión mas reciente Delphi Seatle o Berlin, el detalle que se ha notado que la forma como esta implementado esta generando mucho código en duro ya que todo se define en un solo sitio.

Por ello quise preguntar si es la mejor forma de manejar este tipo de aplicativos ya que si se decide llevar las transacciones a formularios con diseño(.dfm) se tendría que generar por cada transacción y no veo que el problema sea eso ya que como lo mencionaron estos se crean y destruyen cuando se usan, lo que se quiere saber cual es la forma mas eficiente en todo los aspectos.

Espero que ahora si me haya dejado entender el motivo de mi pregunta.

Muchas gracias por sus comentarios.

Muchos programadores no se dan cuenta que la GUI *tambien es codigo* y se puede - y debe - refactorizar.

Es muy probable que se puedan optimizar mucho esas pantallas, y quizas reducir a un numero mas bajo de pantallas "base".

Empiezo por esto, porque lo mas "eficiente" en programación se logra no haciendo micro-optimizaciones, sino mejorando la arquitectura global del sistema.


Yo empiezo por ahi. El mayor "win" sera mejorar la estructura global del sistema, incluyendo el diseño de las pantallas.

Te apuesto que una cosa tan grande y mas aun hecha a las mañas de de una financiera seguro tiene un montón de aberraciones de diseño, que sobre-complican las cosas.


------

Con respecto a lo segundo? Es muy simple, aunque no facil!. Si el sistema debe responder a alteraciones dinamicas de sus requerimientos muy grande es mas productivo a largo plazo hacer un sistema dinamico de GUIs. Pero esto produce resultados sub-optimos en la UX a menos que se piense muy bien la cosa.

Hacer las pantallas "manualmente" puede lograr el mejor diseño/UX (porque se supone que quien hace esas pantallas sabe lo que hace) pero obvio cada cambio hay que hacerlo y recompilar.

Y con respecto a como deserializar las pantallas? Eso no es complicado, pero hay que usar un formato de serializacion adecuado pa' guardar en tablas.

----

Normalmente no me gusta auto-promocionar, pero quizas sea bueno que consigan un asesor para detallar mas el asunto? Conmigo o cualquier otro miembro experimentado puede que te ayuden de forma privada, en especial porque se ve grande el animal y es muy facil encaminarse en una direccion problematica sino se planifica bien...

Puede ser una idea interesante, pero no parece que pueda ser genérica. Es decir, como te han dicho antes, un formulario no sólo son componentes viasuales, sino que muchas veces incluye lógica y código asociado, sea en el formulario o en un modelo separado.
Por ejemplo, se me ocurre que eso podríoa ser válido para las tablas que llamamos "maestros" o "tablas de tipificación" que simplemente sirven para almacenar los diferentes valores posibles a un datos secundario. Estas tablas no suelen tener lógica asiociada.

Para otro tipo de tablas/entidades con "más lógica" no lo veo posible.

Si lo anterior me podía paracer una idea hasta cierto punto aceptable, lo de almacenar todos los atributos en una "SUPERTABLA" me parece un disparate y que conste que lo he visto implementado. Pero como he dicho antes, NO para todas las tablas, sólo para "tablas tipo". Es decir he visto un diseño donde tenían una "TABLA_GENERAL" con los siguientes campos:

TABLA_GENERAL
--------------------
TABLA
CODIGO
DESCRIPCION

Y esta tabla mezclaba valores de la siguiente forma:



Lo dicho. Aunque no me gusta, tal vez tenga sentido para determinadas tablas, pero NO para todas las de la aplicación.


Personalmente creo que no. Aunque en primera instancia pueda parecer buena idea, creao que a la larga no lo es tanto.

No creo.
Puede afectar a otras cosas (complejidad, errores, estabilidad,...) pero no creo que afecte a al rendimiento en gran medida.

No viene mucho a cuento, pero esto me recuerda unos antiguos post de Salvador Jover sobre la creación y herencia de ventanas, que me resultaron muy buenos y útiles para aprender a diseñar desde cero. Todo habla de tiempo de diseño, pero es fácilmente transportable a modo runtime para permitir crear todas las ventanas que nos hagan falta.

Un día con los mayores - Parte I
Un día con los mayores - Parte II
Un día con los mayores - Parte III
Un día con los mayores - Parte IV
Un día con los mayores - Parte V - A
Un día con los mayores - Parte V - B

No se si te serán de ayuda

Saludos

Hola amigo Mamcx,
Gracias por tus comentarios.

Es muy cierto lo que sugieres al inicio ya que la idea principal es reducir la cantidad de pantallas. ya que muchas tienen atributos en común.
Muy cierto que el diseño de los formularios por se dinámico son horrorosos y ahí te comparto una imagen. el hacerlo en forma de diseño de todas maneras va a mejorar el diseño/UX.

Con respecto a como esta diseñado es super complicado ya que encima que es un sistema enlatado, no hay nada de documentación ya que se han metido una fumada de la buena para elaborar esa arquitectura ya que para muchas transacciones se ha tenido que incluir mucho código en duro y la gente que ha intentado darle mantenimiento lo que ha hecho es parchar y/o crear cosas nuevas repetidas por lo complejo de como esta diseñado la arquitectura.

Con respecto a lo ultimo gracias nuevamente por tus comentarios y apenas requiera algo mas avanzado te lo hago saber, Yo he participado en muchos proyectos grande en Delphi como Multi-tier, Modular en Package, Client/Server... pero primera vez que me enfrento a este tipo de arquitectura y por elle requería otras opiniones de colegas con experiencia.