27 respuestas en este tema

[Wilson]

Marc, creo que tienes suficientes razones para optar por esta clase de diseño y desde luego es muy respetable y válida, además de ofrecer al usuario muchas posibilidades sin tener que cambiar de form. Solo quiero recordarte un viejo y machacado refrán "DIVIDE Y REINARÁS", lo digo ante todo por la facilidad para el mantenimiento de la alpicación, por lo demás aparte de luchar en tiempo de dieño con los controles no le veo ningún problema.

Saludos

PD: Marc una pregunta fuera de tópico. ¿Utilizas solo dos transacciones (Lectura - Modificación) para todos los FIBDatasets?

[Sergio]

Marc: Ser gandul ES bueno...

"Si tienes un problema dificil, daselo a un gandul y te encontrará la forma más sencilla de solucionarlo."

Yo no veo justificado sacar todo fuera, si asi va bien y "todos se ven" pues todos contentos, que añadan mas RAM si la necesitan y listo 

[Marc]

Marc, creo que tienes suficientes razones para optar por esta clase de diseño y desde luego es muy respetable y válida, además de ofrecer al usuario muchas posibilidades sin tener que cambiar de form. Solo quiero recordarte un viejo y machacado refrán "DIVIDE Y REINARÁS", lo digo ante todo por la facilidad para el mantenimiento de la alpicación, por lo demás aparte de luchar en tiempo de dieño con los controles no le veo ningún problema.

Sí. Alguna vez he pensado en poner el contenido de las pestañas en frames. De esta forma tendré el código separado (ahora mismo hay tanto código en ese formulario que es difícil de repasar).

PD: Marc una pregunta fuera de tópico. ¿Utilizas solo dos transacciones (Lectura - Modificación) para todos los FIBDatasets?

No, solo utilizo una transacción.

Utilizo herencia visual y cada formulario hereda una transacción del padre de todos los formularios de fichas de datos (junto a los botones de añadir, guardar, borrar, pasar al siguiente, ... y su programación, que es común para todas las fichas de datos).

Todos los componentes de datos usan esa misma transacción (tanto para lectura como para modificación).

Eso lo puedo hacer porqué utilizo ClientDatasets, de manera que la transacción nunca permanece abierta, está siempre cerrada.

Cuando cargo el formulario (o cuando me muevo al siguiente registro, ...), se abren los ClientDatasets, que vía el DatasetProvider, abre una transacción, lee los datos con un FibDataset, los copia a la memoria del ClientDataset, e inmediatamente cierra la transacción.

Los usuarios trabajan con los datos que hay en pantalla, que los mantiene el programa en la memoria de los ClientDatasets, y cuando quieres salir, si le das a guardar entonces ejecutas el ApplyUpdates del ClientDatset. Vía el DatasetProvider, se abre la transacción, se ejecutan una serie de INSERTS o UPDATES para aplicar a la base de datos los datos cambiados en la memoria del Dataset, y se cierra inmediatamente la transacción.

Las transacciones solo duran abiertas unos milisegundos, el tiempo mínimo posible para leer o guardar los datos del formulario, nunca quedan abiertas mientras trabaja el usuario. De esta forma nunca tengo deadlocks, y nunca sobrecargo al Servidor de Firebird.

Es una mecánica que recomiendo a todo el mundo, tan potente y funcional como cualquier otra, pero muy ligera de cara al Servidor (con lo que te ahorras temer que lidiar con incómodos problemas de bloqueos y las brutales caídas de rendimiento que pueden provocar el mantener abiertas transacciones durante demasiado tiempo).

Saludos.

[Marc]

Marc: Ser gandul ES bueno...

"Si tienes un problema dificil, daselo a un gandul y te encontrará la forma más sencilla de solucionarlo."

Yo no veo justificado sacar todo fuera, si asi va bien y "todos se ven" pues todos contentos, que añadan mas RAM si la necesitan y listo 

Parece que me leas el pensamiento, opino exactamente igual.

[egostar]

Ego si sabe como ser ilustrativo

, me pregunto si alguien (sobre todo Marcelo) vió el efecto de Visual Studio.

Salud OS

[Delphius]

Hola,
Disculpen por no venir antes a responder... me había acostado a la 6 am tras estar inmerso en diagramas y apenas había dormido 4 hrs. Cuando desperté estuve sentado con papel y lápiz por lo que la mañana no estuve en la PC.
A la tarde recién me senté en la PC y para las 4 pm mi cuerpo me pedía dormir... desperté a las 7 pm.

Recién está entrando en funcionamiento mi cabeza.

Si, vi el efecto amigo... ¡hermoso y vistoso! 

Marc, te recomiendo el uso de frames. Te ayudará un montón a reducir código y a estructurarlo mejor. Es una gozada que el código esté en el frame y cuando los creas en el form siga funcionando ¡y no tienes que tocar código!.
Seguramente tus forms tienen unos métodos que se encargan de vincular la capa de base de datos con la capa aplicación ortogándole el formato adecuado a la "lógica de negocio".

Sobre si algunos componentes no visuales deban ir en el form o en un DataModule eso me parece que depende de los casos, de las necesidades y la forma en como se encara el diseño de la aplicación.

En lo que yo debería dar un paso es en estudiar el tema de ClientDataSet. Entiendo la idea y el concepto en general (un cliente que trabaja con una "base de datos temporal, en una memoria local" que luego se comunica y actualiza contra la base de datos en cuanto se es necesario) pero como llevaro a cabo, como usarlo y/o porqué se necesita del provider y además del ClientDateSet un DataSet adicional que es el que que realmente se conecta.
El solo verlos me hace trizas la cabeza... tengo que aprender a adaptarme a esa filosofía ya que es la más eficiente en cuanto al uso de las transacciones. Algo bastante crítico e importante.

Bueno, creo que ya encontraste la respuesta a tus necesidades: CnPack. ¿Viste lo completo que es? Ahora bien si ya venías usando GExperts te advierto que en ocasiones puede haber algunos conflictos... algunas veces GExpert y CnPack no se llevan bien. Al menos en mi D6 al iniciar Delphi me salta un AccessViolation por alguna dll que usan (o usa alguno de ellos), pero afortunadamente con volver a iniciar Delphi se pasa... Ahora debes tomarte la paciencia de establecer los "atajos" para cada uno para que no se peleen.

Saludos,

[Marc]

Hola.

Bueno, creo que ya encontraste la respuesta a tus necesidades: CnPack. ¿Viste lo completo que es? Ahora bien si ya venías usando GExperts te advierto que en ocasiones puede haber algunos conflictos... algunas veces GExpert y CnPack no se llevan bien. Al menos en mi D6 al iniciar Delphi me salta un AccessViolation por alguna dll que usan (o usa alguno de ellos), pero afortunadamente con volver a iniciar Delphi se pasa... Ahora debes tomarte la paciencia de establecer los "atajos" para cada uno para que no se peleen.

Definitivamente la solución es CnPack. Pero aún no lo he instalado, precisamente me daba un poco de respeto compartir CnPack y GExpert (y ahora me lo acabas de confirmar, ya que también uso D6).

Pero cualquier día de estos que tenga que trabajar con un formulario demasiado cargado, lo instalo

[ELKurgan]

ya se que no pinta nada, pero en este enlace hay un artículo muy interesante sobre como utilizar Frames dentro de Tabsheets para dividir (y clarificar) el código.

La verdad es que lo he utilizado en algún proyecto y la complejidad de tener muchos frames se ve compensada por el poco código que hay que insertar en cada uno

Saludos