Crear Clases propias o Usar Existentes
 

Hola.
Os importaria darme vuestra opinion, sobre este tema?. A la hira de crear una aplicacion de Gestion, vosotros como programadores experimentados, usarias las clases de conexion con BD exitentes para el 100% de la aplicacion ? o por el contrario usariais vuestras propias clases que a su vez usen las de Acceso a BD?.

Elp roblema seria que no podrias usar los componentes de acceso BD no ?

¿Puedes explicarte un poco mejor? No acabo de entender.
No se pueden usar componentes de Base de Datos.
¿A qué clases te refieres?

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

Código Delphi [-]
 
           type 
                  TArticulo = class
                  private
                      sReferencia : string;
                      sDescripcion : string
                      iCantidad : Short;
                  public
                      property Referencia: string read Referencia write Referencia
                      property Descripcion: string read Descripcion write Dascripcion
                      property Cantidad: short read Cantidad write Cantidad
                      procedure loadFromDB;
           end
 
luego:
 
             procedure TArticulo.LoadFromDB
             begin
                   //codigo de acceso a datos para extraer este Articulo
                   //Rellenar las propiedades del artículo
                   //tarticulos es un TADoTable

                   sDescripcion := trim(tArticulos.fields['Descr'].Value);
                   iCantidad := tArticulos.fields['Cantidad'].Value;
                   .....
                   
             end

Ahora habiora que crear un Objeto de la clase, largarllo de la BD con su metodo y usarlo en el codigo. 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

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

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

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 :D) 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" :D en preguntar.

Un saludo.

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.

¡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

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

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

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.

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.

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

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.

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

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.

Creo que el tiro va por lo de InstantObjects o de Enterprise Core Objects (ECO), incluido este último en el BDS 2006 (.net).

¿Me equivoco?

Información y ejemplos completos de ECO:
http://www.clubdelphi.com/foros/showthread.php?t=42787

:eek:

Sin ver mas alla...
 

Me parece que si hablas de un programa de gestion, estamos hablando de un sistema con varias formularios, funciones, manejo de archivos, etc, etc... Lo que en definitiva te aconsejo usar es una clase existente para concentrarte mas en lo tuyo, si te pagaran bien (por ejemplo). yo siempre acostumbro crear mi propio formato y motor de base de datos, asi consigo lo que exactamente necesito y de una forma que pocos podrian hackear.

Hola,

¿A qué te refieres con "formato" y con "motor de base de datos"? ¿Podrías explicar un poco más? Gracias. :)

Explicacion
 

bueno, formato... defino mi "cabacera" (hash, propietario, privilegios, version, etc), defino mis campos de tablas, mis tablas etc, etc... digamos que trabajo con un "archivo plano"... lo que todos hacen... Una vez hice uno que trabajaba con posiciones absolutas de disco duro bajo el S.O. pero no lo llegue a implementar. consigo BDs de pocos Kb y veloces... dedicados a ser parte de aplicaciones mas que a medida.

En motores, los sub-sistemas que me permiten acceder via SQL (basico), funciones de comprobacion, bloqueo, privilegios, Sockets para trabajar en red, pseudo - triggers, y eso..

Yo tengo una pregunta también.

Si yo empecé con paradox, creando mis clases y mis rutinas de apoyo; después he pasado a Firebird y he hecho lo mismo; ahora me decís que la persistencia es la monda ... si estoy cambiando de esquema de programación cada dos por tres, ¿Cuando voy a reutilizar las clases y rutinas de apoyo que tengo hechas? :D :D

Saludos

Hola,

Desengáñate Lepe, nunca podrás reutilizar ninguna clase. :D :D :D

Tampoco.
 

No dije cual es la moda... digo lo que yo en persona prefiero hacer siempre que la relacion costo/beneficio y tiempo me lo permite. Ahora con el asunto de reutilizacion de tus clases (lepe), pues en definitiva es un problema... habría que evaluar cuanto vale la pena realizar dicha "migracion" , es muy probable que te cueste arto reutilizar tus definiciones antigüas, yo en ese caso crearia una interfaz compatible, un motor que reconozca dichas clases.

Suerte!