Capas o DataAware????

[marto]

Hola a todos,

Cuál creéis que es la mejor manera de atacar a la BD? Me explico, bajo mi punto de vista, existen esencialmente dos técnicas para comunicar nuestro cliente con la BD: Mediante controles DataAware o mediante distintas capas lógicas. Ya sé que existen soluciones intermedias, pero me refiero con soluciones DataAware a quellas que conectan al control de edición con un conjunto de datos (aunque sea una capa intemedia) y con capas a los mecanismos basados en un conjunto de clases (tipo TCliente) que encapsulan la lógica de negocio.
Bajo mi punto de vista la segunda opción es mejor: sistemas más escalables, que "simulan" mejor la realida y por tanto son más claros, mucho menos mantenimiento...
El único contra que le veo es que se desaprovecha buena parte de la potencia que ofrece una herramienta RAD y que el desarrollo es más lento en caso de proyectos muy pequeños.
Pese a todo que los entornos más avanzados nos lleban cada vez más hacia la primera opción. En ASP.NET hasta puedes linkar tus interfaces web directamente a una fuente de datos :eek: (claro, en realidad lo que hace el VS es generar un montón de javascript por debajo).

No lo sé... me gustaría leer todas vuestras opiniones.

[kinobi]

Hola,

Bajo mi punto de vista la segunda opción es mejor: sistemas más escalables, que "simulan" mejor la realida y por tanto son más claros, mucho menos mantenimiento...
El único contra que le veo es que se desaprovecha buena parte de la potencia que ofrece una herramienta RAD y que el desarrollo es más lento en caso de proyectos muy pequeños.

Yo comparto tu tesis.

Hace algún tiempo ya debatimos sobre el tema. Aquí tienes el enlace para que tengas las opiniones que surjan ahora más aquéllas:

http://www.clubdelphi.com/foros/showthread.php?t=197

Saludos.

[kinobi]

Otro hilo donde se trató el tema (en los foros antiguos):

http://www.clubdelphi.com/foros/archivo/viewtopic.php?t=16024

Saludos

[marcoszorrilla]

En la otra ocasión, lei el hilo pero no opiné. Para ser sincero, yo casi siempre utilizo controles enlazados a datos, motivo, me ahorran mucho trabajo, ya están hechos y normalmente satisfacen el propósito perseguido, además de tener una serie de eventos programados.

En ocasiones si es necesario utilizo capas, pero lo mínimo. Me encanta colocar un Tpanel hacer doble clic sobre un Ttable o un Tquery y arrastrar y soltar una ristra de campos sobre él, eso en Clipper o en Cobol o en Basic.... no se podía hacer.

Un Saludo.

[guillotmarc]

Hola.

Siempre utilizo controles data-aware, y realmente són perfectos para desarrollar rapidamente una aplicación.

Aunque un buen amigo, en su empresa ha empezada a cambiar toda su programación, atacando objetos de datos en lugar de atacar directamente a la base de datos. Y me ha empezado a crear dudas.

Hay que admitir que el desarrollo RAD (con controles data-aware) puede llegar a ser una pesadilla en el mantenimiento de la aplicación. Por ejemplo, en la aplicación principal de mi empresa habrá unos 30 formularios atacando a la tabla de productos. Cada vez que tengo que cambiar algún campo de la tabla (pasar un campo de entero a decimal, por ejplo.), hecho a temblar, puesto que paso meses encontrando errores en los sitios más insospechados, provocados por ese simple cambio.

Es el problema de que los formularios no són cajas negras completamente independientes, como deberian, sino que tienen el talón de Aquiles de que todas comparten directamente las tablas de datos. Esto hace que un cambio en la estructura de los datos necesario para un formulario, pueda hacer fallar cualquier otro formulario que los use (aunque no lo hayas tocado para nada).

Mi amigo sostiene que el uso de un OPF (Object Persistance Framework, o algo así) hace mucho más robusto el sistema, al atacar los formularios a objetos, en lugar de acceder directamente a la base de datos.

El desarrollo de la aplicación será más costoso usando OPF que RAD, pero si realmente simplifica drásticamente el mantenimiento de la aplicación, como promete, seguramente el beneficio a largo plazo será mucho mayor.

Creo que hay que tener en cuenta esta alternativa. Lástima que nunca se tiene suficiente tiempo para probar nueva tecnología.

NOTA : Quiero recordar la dirección que proporcionó Kinobi en uno de los hilos anteriormente citados, puesto que estos componentes Open Source pueden simplificar el uso de una capa de datos orientada a objetos. http://www.techinsite.com.au/ (Vienen a ser el equivalente a los controles data-aware, pero en lugar de enlazarse a un dataset se enlazan a un objeto de datos).

Saludos.

[guillotmarc]

Jeje, tengo tantas dudas con el tema, que ni siquiera me decido a votar por ninguna opción.

Espero leer vuestras opiniones.

Saludos.

[guillotmarc]

Por cierto, ¿ alguien conoce los componentes ECO de Delphi 8 ?. Creo que también són para acceder a la base de datos mediante objetos. (Aunque tengo mucha curiosidad, me voy a esperar al nuevo Delphi Win32 para probarlos).

Saludos.

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

[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

[kinobi]

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.

[PepeLolo]

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

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 (http://www.howtodothings.com/showauthor.asp?author=82) 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 (http://groups.google.com.mx/groups?hl=es&lr=&ie=UTF-8&group=borland.public.delphi.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 aurafern@caliescali.com. 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/ViewAuthor.aspx?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