Crear Clases propias o Usar Existentes

[Neftali [Germán.Estévez]]

Ok, ahora entendí un poco mejor (o creo).

Hablamos de usar componentes estandard DataAware (TDBEdit) o utilizar una capa de persistencia on componentes no-DataAware (TEdit).

Empezado por jorllazo

Me refiero pues por ejempplo que uses los componentes de ADO, TAdoTable, TAdoConnection y luego usar el componente TDBEdit por ejemplo para recuperar el nombre de un articulo de la BD? y usar estos componentes TDBEdit, TDBCombo, etc,....
Pôr otro lado a lo que me refiero es crear una clase que sea por ejemplo

Esa es una cuestión bastante importante a decidir y que te va a cambiar por completo la aplicación. Difícil aconsejarte lo uno o lo otro. Deberías leer sobre Persistence FrameWorks (no se por donde empezar); Lee sobre ECO, documentación de Scott Ambler,...

Empezado por jorllazo

...Pero entonces ya no podrias usar el TDBEdit por ejemplo. Tendrias que usar el TEDit y hacer la asociacion de controles y propiedades del objeto a mano. ¿Me he explicado mejor?, si no lo intento de nuevo

No es imcompatible lo uno con lo otro. Los Capas de persistencia también pueden trabajar con los componentes de Base de Datos. Piensa que un componente muestra lo que hay en un DataSet y el DataSet es el que realmente interactual con la BD (graba en disco, recupera,...); Por tanto se puede hacer (yo lo he hecho ) que el componente estandard llegue hasta el DataSet y el DataSet (o derivado) en lugar de grabar de la forma estandard, utilice la Persistencia (tus clases) y SQL para interactuar con la Base de Datos.

Creo recordar que los InstantObject funcionaban de forma similar; No se como lo hace ECO, porque no he trabajado con él...

Espero que te sirva la información y no haerte liado más de la cuenta.
Si tienes más dudas, no "dudes" en preguntar.

Un saludo.

[roman]

Empezado por Neftali

Piensa que un componente muestra lo que hay en un DataSet y el DataSet es el que realmente interactual con la BD (graba en disco, recupera,...);

Pero yo creo que esto depende mucho de cómo se diseñen esas componentes. Tú, mejor que yo, sabes muy bien que una clase en el modelo, no necesariamente tiene correspondencia directa con una tabla de la bd, que es lo que parecería entenderse con el comentario citado.

Empezado por Neftali

[...]se puede hacer (yo lo he hecho ) que el componente estandard llegue hasta el DataSet y el DataSet (o derivado) en lugar de grabar de la forma estandard, utilice la Persistencia (tus clases) y SQL para interactuar con la Base de Datos.

¡Ah! Pero ¿qué significa o cómo haces que un DataSet grabe en forma no estandar?

Siento que en realidad no estoy entendiendo lo que quieres decir con los párrafos anteriores. ¿Podrías explicar un poco más?

Similar a esto, he visto lo que menciona Wayne Niddery aquí pero no sé si es a eso a lo que te refieres.

// Saludos

[Neftali [Germán.Estévez]]

Empezado por roman

Pero yo creo que esto depende mucho de cómo se diseñen esas componentes. Tú, mejor que yo, sabes muy bien que una clase en el modelo, no necesariamente tiene correspondencia directa con una tabla de la bd, que es lo que parecería entenderse con el comentario citado.

Correcto, una clase puede tener una tabla asociado, ninguna o varias (segun el modelo de mapeo que se use en Base de Datos).
A eso me refería a "rediseñar/derivar" el TDataSet(o derivado) para poder hacer lo que necesitemos; Acceder al modelo de persistencia, ejecutar las reglas de negocio,... y finalmente insertar utilizando SQL (en mi caso).

Empezado por roman

¡Ah! Pero ¿qué significa o cómo haces que un DataSet grabe en forma no estandar?¿Podrías explicar un poco más?

Me refería a realizar las inserciones/modificacionea/borrados utilizando sentencias SQL; Ese es mi caso; Tal vez no me expliqué bien...

NOTA: Ahora me leo en artículo...

[Neftali [Germán.Estévez]]

Empezado por roman

Similar a esto, he visto lo que menciona Wayne Niddery aquí pero no sé si es a eso a lo que te refieres.

Lo que comenta este párrafo es básicamente lo que intentaba explicar yo:

Moving data between controls and a data source in no way compromises an OO design because data sources (i.e. TDatasource) do not directly connect to a database and have absolutely no knowledge of the ultimate source or destination of the data that passes through them. Their only role is to provide a single point of connection for any number of individual data-aware controls. That single point of connection is to any descendant of the TDataset class.

Los controles de Base de Datos (TDBEdit, TDBCombo,...) no son el problema; La "miga" y la potencia está realmente en el TDataSet (DataLink); Además, derivado adecuadamente es el que te puede proveer de un FrameWork independiente del SGBD.

Y esto creo que da la respuesta:
Summary

Existing data-aware controls are perfectly compatible with well-designed object-oriented systems. The scorn placed on them by many has been misplaced; the real problem is the routing of data; data-aware controls hooked to datasets that have actual database connections is the problem since this allows data to flow around business logic instead of through it. But it is a problem solved easily by making your business classes responsible for creating the datasets seen by the presentation layer.

Se trata de que los componentes traten con un TDataSet y cortar el flujo de información entre el TDataSet y la Base de Datos, pasándolo al Gestor de Persistencia; Es el Gestor de Persistencia el que se comunica con el SGBD (en nuestro caso en lugar de vía TClientDataSet, como comenta el artículo, utilizando SQL).

A esto me refería con "no grabar de la forma estandard"; En el artículo habla de utilizar un ClientDataset, yo pensaba en SQL directamente.

[Neftali [Germán.Estévez]]

Ya que ha salido el artículo, recomiento revisar en la misma Web (dentro de los Artículos) el que se llama:
Delphi Tools that will Help you

No pongo en link directo, porque no funiona, hay que entrar en la página principal, ir a Artículos y seleccionar este.

[roman]

Empezado por Neftali

(en nuestro caso en lugar de vía TClientDataSet, como comenta el artículo, utilizando SQL).

A esto me refería con "no grabar de la forma estandard"; En el artículo habla de utilizar un ClientDataset, yo pensaba en SQL directamente.

Disculpa mi espesez, pero sigo sin entender. Según entiendo, la idea de Wayne se resume en esto:

La clase TArticulo (por fijar ideas) expone un ClientDataSet al cual se conectan los controles dbaware. Cuando uno llama a, digamos, Articulo.Save, la clase toma los datos del ClientDataSet y los manda a la base de datos. Esto último puede hacerlo- y en la mayor parte de los casos seguramente así lo hará -construyendo una consulta SQL adecuada y pasándosela a la componente que sea menester. Alrevés supongo algo similar. Cuando se llama a Articulo.Load, la clase lanza una consulta SQL y con los datos obtenidos llena un registro del ClientDataSet.

De esta manera entiendo cómo el tráfico entre el control dbaware y el destino final se intercepta y se puede controlar.

Pero con lo que tú dices no entiendo. ¿Como sin usar este ClientDataSet o algo similar controlas este tráfico? Es decir, un DataSet que no sea de memoria, estará comunicado directamente con la bd física, ¿no?

Quizá es que en el derivado interceptes cosas como el Post, por ejemplo. No sé.

// Saludos

[Neftali [Germán.Estévez]]

Empezado por roman

Quizá es que en el derivado interceptes cosas como el Post, por ejemplo. No sé.

La idea es esa exactamente. Se interceptan los métodos de grabar en Base de Datos y se sustituyen por otros que redirigen esas operaciones al Gestor de Persistencia.

Y de una forma similar se hace en la lectura.

Para hacer ese trabajo, almacenar los datos y "ofrecerlos" a los controles da igual utilizar el TClientDataset o el TDataSet; Igualmente el acceso a la Base de Datos se va a realizar desde otro sitio, en ningun caso lo van a realizar ninguno de estos dos controles.

[roman]

Sigo sin entender gran cosa. No veo cómo es que da lo mismo el ClientDataSet que un DataSet cualquiera. Pero gracias de todas formas.

// Saludos

[jorllazo]

Bufff, creo que el que no entendio ya gran cosa, fui yo.
voy a tomarme mi tiempo para leer bien estos mensajes
(no pude antes por que se me han roto 2 PC seguidos oremos por este que queda)

De todos modos, tampoco tengo muy claro como se tendria que hacer esta capa q ofreciera la interfaz de un objeto y que tratase con el acceso a datos. Igual este debio ser mi planteamiento inicialmente, se podria postear algun tipo de ejemplo o link a ejemplos, soy de los que si no lo veen no lo creen.