![]() |
![]() |
![]() |
![]() |
![]() |
FTP | ![]() |
![]() |
CCD | ![]() |
![]() |
Buscar | ![]() |
![]() |
Trucos | ![]() |
![]() |
Trabajo | ![]() |
![]() |
Foros | ![]() |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
![]() 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. |
#2
|
||||
|
||||
Cita:
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...
__________________
El malabarista. |
#3
|
||||
|
||||
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 |
#4
|
||||
|
||||
![]() 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. |
![]() |
|
|
![]() |
||||
Tema | Autor | Foro | Respuestas | Último mensaje |
diversas Lineas y figuras dentro de formulario en delphi en modo diseño | thelibmx | Gráficos | 6 | 04-04-2008 01:08:37 |
Cambiar propiedad de componente del formulario padre al cerrar el formulario hijo | jzginez | OOP | 5 | 22-06-2007 21:40:51 |
Evento onclick en formulario dinámico | jfgaliano | OOP | 1 | 23-12-2005 14:05:46 |
Formulario dinámico | jfgaliano | API de Windows | 2 | 23-12-2005 13:39:03 |
pasar datos de un formulario vista a cualquier formulario | @-Soft | OOP | 2 | 28-09-2004 21:56:01 |
![]() |
|