Capas o DataAware????

[haron]

el problema que veo en los componentes dataAware es que implementan demasiada funcionalidad, tanta, que muchas veces se salta la logica de negocio.

seria interesante diseñar unos componentes dataAware con funcionalidad minima, de manera que obedeciesen las reglas de negocio.

estos componentes deberan estar sujetos a las siguientes premisas:

"una fuente de datos es una coleccion ordenada de filas y columnas con un primer registro"

"las inserciones, actualizaciones y borrados corren a cargo del programador y por tanto pueden estar sujetas a alguna logica de negocio"

la primera afirmacion no dice nada acerca de la procedencia de esa informacion (que puede venir de fuentes distintas) ni que esa coleccion ordenada de filas tenga un ultimo elemento, por ejemplo.

el componente podria tener los metodos 'delete' y 'post' que disparan los eventos 'onDelete' y 'onPost' donde el programador escribe el codigo necesario para llevar a cabo estas acciones (que no tienen porque coincidir con un 'delete', 'insert' o 'update' del SQL).

unos componentes asi nos ahorarrian mucho trabajo de cara a la visualizacion de la informacion.
bueno, es una opcion.

si he dicho alguna tonteria, por favor haganmelo saber.

[andres1569]

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 ...

[kinobi]

Empezado por andres1569

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.

Sí, el tiOPF de techinsite se basa en eso y aun va más lejos. Ya que en las fases de análisis y diseño no trabajas con TEmpresaDataSet ni TProveedorDataSet, sino con Empresa y Proveedor (sin pensar en DataSets, en el sentido de DataSet Delphi), lleva esa idea a la fase de codificación, de tal forma que te abstraiga del mecanismo de persistencia que utilices para los objetos de tu sistema.

No son los únicos, recuerdo haber utilizado hace años una biblioteca que hacía algo parecido: Spider (por cierto, creo que ahora también es Open Source).

Saludos.

[brandolin]

He votado por Objetos ya que tuve la grata mala experiencia de usar solamente DataWare y el mantenimiento del sistema terminado es un desquicio.

Ahora estoy desarrollando algo nuevo y estoy utilizando Objetos, pero no puros. Solamente los uso para las Altas, Modificaciones y bajas de los datos en donde encapsulo toda las reglas de negocios. Para las consultas, vistas en grillas, o en forms. etc, etc. utilizo, directamente los Dataware, ya que brindan la posibilidad de utilizar una alta gama de componentes existentes que dan flexibilidad a la hora de programar.

Tambien hice una aplicacion donde la empece con Objetos y luego "por tiempo" la termine con DataWare. Conclusion: La parte donde estan los objetos... sin problemas, funciona limpiamente, facil de mantener y actualizar, agil en los manejos de datos y veloz al usuario. En la parte con DataWare.... todo un rollo.... mejor no tocar una linea porque se cae todo el sistema....

Sigan opinando...

PD: Me interesaria conocer algun articulo "en castellano" donde toque el tema de Diseño con Objetos. He leido varios y son todos buenos, si alguno sabe de otro... a decirlo

[PepeLolo]

Noto que falta una mezcla de ambas, Datawarezes y Capitas de espadachin ala triste, en esta encuesta

Veamos desde mi pequeño punto de vista lo ideal es una mezcla de ambos, una capita que me abstraiga de la conexión a la BD, vamos definición virtual de los datos, metodos, eventos, etc. De modo que no encuentre problemas con mis controles Dataware que pueda conectar posteriormente a esta capita. Con esto lo que quiero decir es que: Sí hoy mi campo es entero y mañana es Decimal, lo soporte sin cambios en mí programita. Lo mismo Campito TStringField y mañana Campito TMemoField sin perjucio de tener que volver a compilar y cargar mís TFIelds que conectaré con mis componentes especiales Dataware para que todo el proceso con la Bd, me los gestione el solito.

Saludos

[lafirma]

Donde puedo encontrar informacion y/o tutoriales acerca del asunto de las capas, ingles o espanol...

[guillotmarc]

Los componentes citados http://www.techinsite.com.au/ tienen una documentación muy buena, con una buena introducción al tratamiento de datos mediante objetos.

Saludos.

[roman]

A manera introductoria podrías leerte los artículos de Phil Brown comenzando con "Implementing business objects". Muy interesantes, sencillos de leer y para cosas no demasiado complejas pueden servirte de punto de partida.

También puedes encontar mucha información en el grupo de noticias de borland de oodesign donde les fascina hablar de opfs (object persistance frameworks)

// Saludos

[aurafern]

No he podido ingresar al enlace articulos, podrias enviarme los articulos que tengas sobre el tema a este e-mail [email protected]. De verdad llevo mucho tiempo tratando de averiguar sobre esto, y pincho el enlace pero aparece la página de error. Gracias de antemano

[roman]

Veo que rediseñaron el sitio y cambiaron los enlaces.

Con este enlace

http://www.howtodothings.com/ViewAut...px?Author=1246

accedes a todos los artículos de Phil Brown. Son ocho en total pero me parece que dos de ellos son de otra cosa. Comienza con el que se llama Implementing business objects y al final de cda artículo está el enlace al siguiente.

// Saludos