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

[__marcsc]

Hola compañeros,

a raiz de un post del amigo roman y recordadome un post que se alargó bastante cuando se estrenaron los foros anteriores (y dado que se ha perdido el susodicho mensaje) me dispongo a iniciar este eterno debate.

La cuestión es sencilla:

- Como desarrolladores de Soft, usais controles DBAware? En tal caso porqué? En caso contrario, por qué no?

Como experiencia personal diré que a mi me gusta usar los controles DBAware porqué creo que me representan un ahorro importante de tiempo (para eso Delphi es una herramienta RAD) y porqué me da más seguridad utilizar código probado (en teoría ) de compañias que se dedican a eso. Asumo que consumimos más recursos pero dado la comodidad que me proporcionan es un precio que estoy dispuesto a pagar

Se admiten opiniones de todo tipo.

Un saludo.

[kinobi]

Hola,

siendo sincero, para casi todo lo que he hecho con Delphi y bases de datos he utilizado controles enlazados a datos. ¿Razón?, lo que tú comentas: comodidad y cierta seguridad en los autores de los controles.

Ahora bien, más que ver los problemas en el consumo de recursos (que también), yo veo el problema en la "desadaptación de impedancia" (el concepto no es mío; lo encontré por primera vez en un artículo de Scott Ambler) entre los modelos, por lo general relacionales, de base de datos que utilizamos para el almacenamiento, y los modelos orientados a objeto que utilizamos para el desarrollo de los clientes y/o servidores de aplicación.

Vamos, que el modelo de datos de clientes, productos, proveedores, ..., que diseñamos y con el que trabajamos en la base de datos tenemos que "traducirlo" a DataSets: QueryClientes, QueryProductos, DataSetProveedores, ..., necesarios para los controles enlazados a datos, en vez de utilizar objetos (clases) TCliente, TProducto, TProveedor, ...

Existen alternativas, unas partiendo desde cero, otras con productos de terceros, pero es difícil llevarlas a la práctica cuando uno sufre presiones en cuanto a presupuestos, plazos de entrega, un cliente o un jefe que entiende el desarrollo de software como si fuese una máquina de hacer chorizos ...

Saludos.

[__cadetill]

Hola

He votado que SI por la sencilla razon de que los utilizo en todas mis aplicaciones con bases de datos. Motivo, muy sencillo, me ahorran gran cantidad de trabajo.

Os imaginais lo costosa que resultaria una aplicacion que atacase a Interbase utilizando el API (a nivel de horas de programacion, claro)? Pues esas horas se han de cobrar al cliente final y, el precio se le dispararia.

Claro esta que, a base de hacer programas, uno se crearia su propia unit de funciones y procedimientos de conexion, pero... para que hacerla si ya esta hecha? O es que tenemos que reinventar la rueda? Y a mas, la mayoria de componentes de acceso a bases de datos estan mas que provados y, si todo y eso se encuentra algun bug, estan los fuentes para mirarlo y poder corregirlo.

Pues nada, que no quiero enrollarme mas. Nos leemos

[kinobi]

Hola,

Posteado originalmente por cadetill
Os imaginais lo costosa que resultaria una aplicacion que atacase a Interbase utilizando el API

Parafraseando un anuncio de TV de hace unos meses ... "No tiene precio".

Aunque es cierto que existen soluciones intermedias, p. ej. "TechInsite Object Persistence Framework" (http://www.techinsite.com.au/), que ofrece un marco de persistencia que incluye extensiones, entre otras bases de datos, para InterBase a través de IBX. Además es Open Source.

Posteado originalmente por cadetill
O es que tenemos que reinventar la rueda?

Esto me recuerda al manual de "Turbo Vision" para C++, que utilicé hace años. Uno de los capítulos, de los primeros, trataba de convencer de las bondades de Turbo Vision con una frase que jugaba con los conceptos OOP: "No reinventes la rueda, herédala"

Saludos.

[roman]

Je, je. Bueno, pues no sé qué contestar.

Durante mucho tiempo he utilizado controles dbAware sin mayores problemas aunque siempre ha habido "algo" que no termina de gustarme: me siento en medio de una jungla de eventos que se disparan en los momentos más insospechados.

En los últimos tiempos he estado trabajando en un sistema de control escolar utilizando Paradox y harto ya (de Paradox) y dado que hemos empezado a trabajar procesos vía Internet he optado por cambiar a MySql. Acabamos de efectuar con éxito nuestras primeras inscripciones en línea y aunque no se trató de procesos muy complejos, lo cierto es que me sentí muy a gusto trabajando con PHP y MySql y no extrañé para nada los controles dbAware. Es sencillamente otra forma de trabajar; no necesariamente mejor o peor, sino todo lo contrario

Actualmente estoy en proceso de migrar todo el sistema de Paradox a MySql y planeo realizar todos los módulos de uso interno con Delphi. Cuando busqué opciones para acceder a MySql desde Delphi ví, desde luego, dbExpress y Zeos pero, habiendo ya programado PHP-MySql me di cuenta que al igual que con PHP no es nada difícil programar directamente con la API de C-MySql y preferí esta opción pues me daba un acceso directo (recordemos que cualquier a acceso a MySql en Windows se hace, a fin de cuentas, a través de libmysql.dll)

Siendo además que varias partes del sistema tendrán acceso ya sea por Internet o desde una aplicación en Delphi, el paralelismo entre el Api de PHP-MySql y el de C-MySql me hace muy sencillo escribir para uno habiendo escrito el otro.

Claro que tampoco soy tan necio y no pretendo estar escribiendo

conn := mysql_init(nil);
if conn = nil then
  raise Exception.Create('Error');

if mysql_real_connect(conn, host, user, passwd, db, 0, nil, 0) = nil then
  raise Exception.Create('Otro error');

if mysql_query(conn, sqlstring) <> 0 then
  raise Exception.Create('Qué creen: error!');

rows := mysql_store_result(conn);

{ otras comprobaciones } 

row := mysql_fetch_row(rows);
while row <> nil do
begin
  { Hacer algo con row }
  row := mysql_fetch_row(rows);
end;

para cada simple consulta, sino que pretendo diseñar un conjunto de clases (interfaces de hecho) que se encarguen de las partes pesadas.

Así que, cuando termine estaré en mejor posición para votar

// Saludos

[haron]

creo que hay que reutilizar en todo lo posible los recursos existentes.

a veces el coordinador del equipo no le gustan los componentes, dicen que son feos y otras panplinas. crea unos componentes que tienen unos colores muy bonitos, pero que no son dataware. y ala, carga para el programador!

bueno, tambien es cierto que muchas veces la consulta que esta enlazada a los controles data aware no son actualizables. en este caso esta justificado el uso de otros controles.

pero en general, creo que hay que obedecer a la premisa de la programacion orientada a objeto de reutilizar codigo.

hastaluego!

[X-JABS]

Seguro que si dbAware!

Ya no hay que reinventar la rueda!

a veces el coordinador del equipo no le gustan los componentes, dicen que son feos y otras panplinas. crea unos componentes que tienen unos colores muy bonitos, pero que no son dataware. y a la, carga para el programador!

esto a pasado, pero hasta estos controles lo he hecho dbAware, recuerdan el FlatStyle, que hay un link a estos componentes aquí, pues los he hecho dbAware..

todo para el bien de los colores y la belleza..!

[haron]

claro que si.

cada empresa debe tener su propia firma de identidad. usar unos controles que lo caractericen, etc.. etc... y sobre todo que sea bonito, porque eso vende mucho.

pero lo que no se puede hacer es mermar la eficacia del programador solo por la estetica del programa.

a mi lo que no me gustan son las decisiones a la ligera que toman algunos responsables y luego ni te escuchan y te miran como si les estuvieses robando algo, cuando lo que en el fondo quieres es participar. aararrag! me ponen de los nervios.

claro, vivimos en una sociedad capitalista en la que el jefe (el dueño de tu fuerza de trabajo, el que tiene el dinero) es el que la puso a la cabeza (perdon, se me ha escapado que es una tia?) pues le caia en gracia, cuando en el fondo quien debe elejir a sus representantes es el propio grupo de trabajo....

en fin. mierda de capitalismo.

[bitERROR]

Buenas gente, Yo no los utilizo

Considero que la aplicación gana en flexibiliad y seguridad, permitiendo al usuario modificar el contenido de los controles no dbaware con la conciencia de que no alterará ningún valor previamente almacenado en la BD hasta que no pulse el botón Aceptar a la vez de eliminar, en mayor parte, la pesadez de calcular campos dependientes de otros y así conseguir una operatoria más rápida.

Lleva más trabajo y tiempo, pero no mucho más sinceramente. Y también me obliga a:

if a = 0 then raise exception.create('error 1');

if b < 0 then raise exception.create('error 2');

if b >= a then raise exception.create('error 3');

etc...

pero esta ristra de errores la verá el usuario hasta el momento en que sea capaz de preveerlos, porque en ningún caso serán errores de aplicación sino por valores incorrectos entrados por el usuario.

Igual os sorprendería la velocidad a la que se adaptan los clientes al funcionamiento del programa.

Pufff, son las 3.30!!! tengo que irme al sobre, iba a escribir no se que más, mañana pasaré a ver si me acuerdo y acabo con este posteo, ta lueksss

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

[Alfredo Soler]

Yo vote que no. Como menciono MARTO si la aplicación es pequeña no hay problemas puedes resolverlo con los componentes dbaware y nadie se queja todos felices y contentos. Pero mi experiencia con un sistema que conecte por Internet al principio fue desastrosa, al usar estos componentes la aplicación se ponía muy lenta y necesitas dedicar mucho tiempo para poder hacer que mejoren estos tiempos, pero decidimos cambiar para componentes no dbaware y encontramos que es mucho mejor ya que tu puedes controlar la carga de datos del servidor con mayor facilidad y puedes minimizar el uso de la red que es lo que realmente pone lento al sistema.

[jceluce]

Hola Gente,

Hasta ahora siempre he usado controles dbAware, pero creo que depebde de la aplicación a realizar. No tengo problemas en no usarlos si considero que una aplicacion no los necesita o es más rápida sin ellos. El secreto está en saber evaluar que es lo más conveniente para cada aplicación.

[fvazquez]

Como se puede conectar a un servidor que no sea el localhost? Ya lo probe y tengo problemas con los servidor externos.
Gracias.

[roman]

fvazquez:

Siendo éste tu primer mensaje en los foros te doy la bienvenida y te invito para que te tomes unos minutos para leer la guía de estilo con el fin de que conozcas la mejor forma de colocar tus preguntas. La que aquí haces no está relacionada con la temática de este hilo.

Asímismo, en lo que se refiere al mensaje privado que me enviaste, te sugiero primero que realices una búsqueda en los foros ya que existe la posibilidad de que el tema se haya tratado anteriormente, y si tienes alguna duda te recomiendo que abras un nuevo hilo aquí en los foros de forma que todos puedan beneficiarse, aumentando además las posibilidades de encontrar una respuesta satisfactoria.

// Saludos

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