Data-aware o no data-aware... esa es la cuestión!

[marto]

He votado que no aunque en realidad pienso que depende. En aplicaciones relativamente pequeñas, los DBAware son muy cómodos, y si el programa no tiene gran complejidad lo haremos rápido y bien.
Sin embargo encuentro que este tipo de componentes nos llevan a una programación basada en objetos y no orientada a objetos, y para eso ya tenemos VB que es más facil.
Es cierto que podemos hacer OOP creando nuevos controles, pero yo me refiero más al control de la lógica de la empresa. Ya alguien en este hilo ha apuntado este problema, yo puedo encapsular qué es un cliente, sus validaciones y procesos dentro de mi clase TCliente, pero si despues enlazo el campo para editar su NIF directamente al dataset y este a la BD me estaré pasando dicha clase por los mimisimos h...
En consecuencia, en aplicativos más o menos largos, el uso de componentes enlazados a datos nos conduce a una mayor probabilidad de errores y a tener el código disperso entre "eventos que se disparan cuanto menos lo deseas".
Quizá mi opinión es un tanto radical, pero lo cierto es que en mi experiencia, los controles DBAware me han traído más problemas de lo que me han solucionado.
No me enrrollo más, a ver que os parece lo dicho...

[ASAPLTDA]

Hola Marto
yo uso dbaware la mayor parte de mis desarrollos. Veo que tu utilizas objectos para intercambiar datos entre controles visuales y la base de datos , podrias donar a los usuarios del clubdelphi un ejemplo concreto (muy sencillo) en delphi (fuentes) de como se usa esta tecnica para poder evaluar y utlizarla?
Gracias por tu Atencion
Carlos Ramirez

Empezado por marto

He votado que no aunque en realidad pienso que depende. En aplicaciones relativamente pequeñas, los DBAware son muy cómodos, y si el programa no tiene gran complejidad lo haremos rápido y bien.
Sin embargo encuentro que este tipo de componentes nos llevan a una programación basada en objetos y no orientada a objetos, y para eso ya tenemos VB que es más facil.
Es cierto que podemos hacer OOP creando nuevos controles, pero yo me refiero más al control de la lógica de la empresa. Ya alguien en este hilo ha apuntado este problema, yo puedo encapsular qué es un cliente, sus validaciones y procesos dentro de mi clase TCliente, pero si despues enlazo el campo para editar su NIF directamente al dataset y este a la BD me estaré pasando dicha clase por los mimisimos h...
En consecuencia, en aplicativos más o menos largos, el uso de componentes enlazados a datos nos conduce a una mayor probabilidad de errores y a tener el código disperso entre "eventos que se disparan cuanto menos lo deseas".
Quizá mi opinión es un tanto radical, pero lo cierto es que en mi experiencia, los controles DBAware me han traído más problemas de lo que me han solucionado.
No me enrrollo más, a ver que os parece lo dicho...

[Casimiro Notevi]

Simplemente, sí.

[FunBit]

Yo los utilizo, ya que cuando entré en el proyecto base a que se dedica la empresa donde trabajo ya los estaban utilizando.

Saludos!

[ASAPLTDA]

yo uso dbaware la mayor parte de mis desarrollos. Veo que algunos foristas utilizan objctos tal como TCLIENT,TPRODUCTO,T..ETC para intercambiar datos entre controles visuales y la base de datos , podria algun forista donar a los usuarios del clubdelphi un ejemplo concreto (muy sencillo para superDummies ) en delphi (fuentes) de como se usa esta tecnica para poder evaluar y utlizarla?
Aprovecho y reitero la pregunta sobre como implementar el artiuclo de soluciones vulcano clic,clicl run, cracks que tambien aplica a este tema. O si alguien conoce algun sitio donde este esplicado la implmentacion en codigo no ayudaria mucho

Gracias por tu Atencion
Carlos Ramirez

[mamcx]

Despues de mucho trayecto, ahora tengo una inclinacion mas "hibrida" en cuanto al acceso a datos.

Resulta, que como dice kinobi, no hay una relacion directa entre los objetos, tal como los definen los lenguajes OO, y las estructuras de datos. Pero iria mas alla: Es una PERDIDA de tiempo intentar que los conceptos OO mapeen 100% a las estructuras de datos y viceversa. Es una perdidad tal, que una solucion definitiva NO existe a pesar de los multiples intentos.

Analicemos la cosa. Hay (3) formas fundamentales, 3 paradigmas grandes de acceso a datos:

1-Estilo DataSet ( o sea, como Delphi, ADO, ADO.NET):

El estilo dataset es nada mas ni nada menos un manejo de matrices mas sofisticado, con opciones de lista, navegacion y edicion. El estilo DataSet representa perfectamente un conjunto de filas y columnas y provee excelentes y simples maneras de trabajar con ellas.

En mi opinion, Delphi tiene la mejor implementacion de este tipo de acceso, por encima de todos los demas. Es flexible, es intercambiable, no altera la parte visual y combinando con dataset en memoria, MUY facil de volverlo un objeto, usando encapsulamiento y polimorfismo.

Mi tabla de puntaje mediane mis propias conclusiones:

- Listar datos : ++++
- Velocidad : +++
- Modificar datos : +++
- Programar objetos negocios, procesos complejos: +
- Complejidad: ++/+++

2- Estilo objetos: Es lo que hace ECO, Bold, TechInsite y otros. De estos, me parece que ECO es lo mejorcito de lo que he visto, incluyendo cosas de Java como hibernate. Sin embargo, siempre utilizan en sus adentros uno de los otros dos estilos o el acceso directo a la API y se vuelve una gran carga en sentido de la cantidad de indirecciones que hacen. Pero para hacer modelamiento de objetos de negocios, es lo mejor.

- Listar datos : +/++
- Velocidad : ++/+++
- Modificar datos : +++
- Programar objetos negocios, procesos complejos: ++++
- Complejidad: +++

3- Estilo comando: Entre este estilo incluyo a lo que hace DBase, FoxPro, PHP, Ruby y Linq. Basicamente, es hacer asi (al estilo Fox): UPDATE Salario WITH Salario*50

- Listar datos : ++++
- Velocidad : ++++
- Modificar datos : ++++
- Programar objetos negocios, procesos complejos: +
- Complejidad: ++/+++

Pero despues de mucho batallar entre data-aware y no data-aware, hacer mis propios intentos de un OPF y de probar los de tech-insite, Bold y ECO, simplemente me he rendido a la realidad:

1- Si quieres listar cosas y hacer informes: DataSet / Estilo DBase/Fox
2- Si quieres modelar objetos de negocios, procesos: Programa TUS propios objetos y "esconde" los dataset/comandos en el interior o integra un OPF y si es algo mas complejo, un modelo como ECO
3- Si quieres hacer procesos complejos, usa OO + Comandos y/o llamadas directas SQL

Esto es como preguntar: Uso matrices o Colecciones, o arboles, o nodos, o listas enlazadas o doble enlazadas o punteros? Sobre los mismos datos no todas las formas de representarlos y manipularlos producen los mismos resultados, unas veces hazlo como una matriz, pero luego se pasa a una coleccion pero para aquello haz un arbol... pero el arbol es complejo, dale con nodos pero luego son nodos de conexiones debiles, tira punteros, etc....

Y no hay razon para no hacer mezclas. Por ejemplo, como dice Kinobi, la interface de PHP es pateticamente simple, la razon? es muy estilo FoxPro . O sea, como no sera mas sencillo:

RetornarDataSet('SELECT * FROM Clientes',SoloLectura):TClientDataSet

que voltear con los objetos, configurar conexiones, etc... (que es la forma manual de hacerlo con DataSet)

Pero a la vez, como no va ser mas simple, pegar un reporte, conectarlo a dataset, configurar la ubicacion de los campos y listo?

Pero como no va a ser mas simple, hacer un diagrama de estado, cojer ECO, decirle generar y !pow! tienes programado, ejem..., listo, tu sistema con Workflow automatico con persistencia de datos a xml, sql server, firebird, con evolucion de version, etc...?

Es por eso, que ahora con Delphi pongo los dataset para que me hagan los combos, las listas, los reportes y Grids. Hago mis propios objetos, que NO utilizan estos dataset, para los procesos, nada de eventicos por ahi sueltos en los dataset, TODOS en los objetos. Y lo programo para que me recuerde a mi fox, por medio de comandos como ObtenerDatos('Select... y EjecutarSql('Insert...

Y asi deje de peleear con esto...

[vtdeleon]

Saludos

Mi respuesta es SI. Aunque me ha surgido la idea de hacerlo de otra forma, pero con el solo hecho de pensar en todo el codigo de desarrollo y el tiempo qeu sera invertido, pues me hecho pa'tra.

Empezado por Casimiro Notevi

Simplemente, sí.

[Casimiro Notevi]

Empezado por vtdeleon

Saludos

Mi respuesta es SI. Aunque me ha surgido la idea de hacerlo de otra forma, pero con el solo hecho de pensar en todo el codigo de desarrollo y el tiempo qeu sera invertido, pues me hecho pa'tra.

En principio, sí. Aunque siempre hay excepciones a la regla

Es lo más rápido y cómodo para formularios simples, listas rápidas, informes, etc.

Sin embargo para formularios "complejos" de peticiones de datos no los encuentro demasiado cómodos de usar.

[joaquipardo]

Sres.
Estoy viendo en internet algún componente sencillo en donde se pueda desarrollar más facilmente las reglas de negocios, por ejemplo.
Un campo sum(X) > Y de otra tabla.
Un campo Z = 2, hace un foco en tal cosa llamando a varios procedimientos.
Un campo N sea buscado en otra tabla si existe.
Todo esto para no estar haciendo programación tediosa de validaciones, controles y otras cosas más que les lleva mucho tiempo desarrollando.
Esto que les digo si lo tiene Java que son motores de reglas de negocios que son mucho más complejos.
En sintesis si me pueden decir si existe o no existe algún componente confused: , es muy importante para mi.

[Koder]

SI.

Cuando realicé mis primeras incursiones Delphi + BD elegí trabajar sin controles dbAware por una pequeña manía de controlar los procesos en mis programas hasta el último detalle (hay que avisarme a mí primero si cambian los datos ) Luego descubrí las ventajas de los controles dbAware y me ahorré varias líneas de código, pero como no pierdo mi manía sigo utilizando los clásicos botones Aceptar y Cancelar que realizan el Update cuando yo lo autorizo (lo mismo con las otras operaciones) . Incluso he derivado algunos controles no dbAware para realizar mis propios dbAware y así practico un poco mi OOP

En fín SI pero poniéndole restricciones