Cita:
Empezado por Maniches
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
|
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).