|
No creo que ambas opciones sean excluyentes. Me explico: el que usemos controles DBAware para la visualización/entrada de datos, conectados a sus respectivos Datasets, no excluye el uso de clases que encapsulen la lógica o regla de negocio.
Esto lo he aplicado en alguna ocasión, a saber, en un programa de contabilidad general, donde los asientos de diario se trabajan/guardan al margen de los asientos de borrador. Aun siendo tablas aparte y con algún matiz que las diferencia, en ambos casos se les aplica un tratamiento similar, por lo que implementé una clase que recibía sendas tablas y les que aplicaba las reglas de negocio (esto jugando con los eventos y propiedades de las mismas de forma que no había que hacer asignaciones de eventos desde el IDE). La clase en cuestión estaba preparada para recibir y actuar sobre campos con diferentes nombres. La carencia de este diseño, tal como apunta Marc Guillot, es la dependencia que sigue existiendo de los controles DBAware respecto a los nombres de los campos, en eso la clase no puede hacer nada, ahí sí que se echa en falta un tipo de Dataset flexible/inteligente que permita "engancharse" a otros Datasets traduciendo los nombres de campos, y al cual enlazaríamos los controles. Ese Dataset sería la capa intermedia que echamos en falta, y el que podría encargarse el solito de controlar las reglas de negocio.
No sé si esos componentes que citáis ya hacen algo similar pero seguro que se puede programar algo similar, algo al estilo TClienteDSet, un descendiente de TDataset que a la vez sepa entenderse con un TEmpresaDSet, TProveedorDSet ..., y que sepa engancharse a diferentes estilos de bases de Datos aplicando reglas de negocio y a la vez siendo accesible desde los controles DBAware.
No divago más, seguro que alguien tiene hecho algo por el estilo ...
|