PDF de programación - Aplicaciones de bases de datos con Delphi

Guías técnicas Grupo Danysoft:
Aplicaciones de Bases de
Datos con Delphi



Equipo Grupo Danysoft
junio de 2003 - (902) 123146
www.danysoft.com

Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi



Este documento se ha realizado utilizando Doc-To-Help®, distribuido por :



Danysoft Internacional
Avda de España 17
28100 Alcobendas – Madrid
Tfno. 902.123146
Fax. 902.123145
http://www.danysoft.com
http://www.danyshop.com
[email protected]



www.danysoft.com - Página 2/9

Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi

Aplicaciones de bases de datos con Delphi

Una estrategia para su desarrollo

Las aplicaciones de bases de datos son por mucho el tipo de aplicaciones más
desarrollado con Delphi. Si bien Delphi es una herramienta de desarrollo de
aplicaciones de propósito general, está provisto de herramientas muy potentes
especialmente orientadas al desarrollo de aplicaciones de bases de datos.
La mayoría de los artículos dedicados al desarrollo de aplicaciones de bases de datos
con Delphi no son más que una mera descripción de los componentes disponibles y de
sus principales características. Este artículo es diferente ya que en su contenido os
presentaré una estrategia para el desarrollo de aplicaciones de bases de datos con
Delphi. Es sabido que estrategias hay muchas, quizás tantas como progadores, y que
no hay una estrategia que sea la mejor en todos los escenarios, posibles e imaginarios.
Por lo tanto mi objetivo no es presentaros "la" estrategia sino "una" estrategia que
sirva de base y ejemplo para la elaboración de la vuestra propia.

ClientDataSet y DataSetProvider

La estrategia que os presentaré está basada en el componente ClientDataSet. Este
componente está disponible en Delphi desde la versión 3 como parte de la tecnología
MIDAS. Mucho tiempo ha pasado desde entonces y en la versión actual, es decir, en
Delphi 7, la tecnología MIDAS ha sido bautizada DataSnap y el componente
ClientDataSet, si bien sigue siendo una pieza fundamental de esta tecnología, no es
exclusivo de ella. Hasta la versión 6 el componente ClientDataSet sólo estaba
disponible en la edición Enterprise y su uso estaba sujeto a condiciones especiales de
licenciamiento (Si, estoy hablando de $$$). En Delphi 7, el componente
ClientDataSet no sólo está disponible en la edición Professional sino que su uso ya no
está sujeto a ningún tipo de licenciamiento.
Si bien el componente ClienteDataSet es un DataSet tiene varias particularidades que
lo diferencian de los DataSet tradicionales. Las más importantes son las siguientes:
• El componente ClientDataSet no obtiene los datos directamente de una fuente

de datos sino indirectamente a través de un componente DataSetProvider.

• El componente DataSetProvider realiza dos tareas principales:

o Provee datos. Para ello debe estar relacionado con un DataSet.
o Aplica actualizaciones. Para ello genera sentencias SQL de INSERT,

DELETE y UPDATE y gestiona transacciones automáticamente.

• El ClientDataSet mantiene los datos en memoria y puede trabajar

completamente desconectado de la fuente de datos. No sólo mantiene en
memoria los datos obtenidos sino también las modificaciones realizadas.

Para quienes utilizáis Delphi desde hace tiempo quizás estas características os resulten
familiares, ya que son similares a las disponibles con el uso de "cached updates" y el
componente UpdateSQL.
La siguiente imagen de pantalla muestra un formulario con los componentes
ClientDataSet y DataSetProvider.



www.danysoft.com - Página 3/9

Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi



Lo que sigue es una descripción ordenada de lo que ocurre detrás de escena cuando
utilizamos un componente ClientDataSet:

1. Cuando abrimos el ClientDataSet, éste le pide datos al DataSetProvider

asociado por medio de la propiedad ProviderName (en este caso
DataSetProvider1).

2. El DataSetProvider le pide datos al DataSet asociado por medio de la

propiedad DataSet (en este caso Table1).

3. El DataSet obtiene datos de la fuente de datos correspondiente (en este caso la

tabla "Country.DB" del alias "DBDemos") por medio del componente de
conexión asociado (en este caso Database1).

4. El DataSetProvider construye un paquete con los datos obtenidos y se lo envía

al ClientDataSet.

5. El ClientDataSet mantiene el paquete de datos en memoria y mantiene por

separado otro paquete de datos conteniendo las modificaciones realizadas por
el usuario.

6. Cuando se ejecuta el método ApplyUpdates del ClientDataSet, éste construye

un paquete con las modificaciones y se lo envía al DataSetProvider.

7. El DataSetProvider se encarga de aplicar las actualizaciones directamente con

la fuente de datos sin pasar por el DataSet asociado (en este caso el Table1).
Para ello genera sentencias SQL de INSERT, DELETE y UPDATE y
actualiza cada registro en el contexto de una transacción.

Existe un mecanismo para la resolución de errores de actualización pero por el
momento no lo describiré.

Una capa de abstracción

Mediante el uso de los componentes ClientDataSet y DataSetProvider estamos
introduciendo una capa adicional entre la lógica de datos y el acceso a datos.
Podríamos verlo como un modelo de tres capas:

1. Capa 1: acceso a datos.
2. Capa 2: lógica de datos.
3. Capa 3: lógica visual.

Por supuesto estas tres capas son lógicas y están contenidas en un único ejecutable.
Sin embargo, si las diseñamos bien podemos modificarlas individualmente sin que
ello nos obligue a modificar las otras capas.
Hasta Delphi 4 las cosas eran más simples porque teníamos menos alternativas. Sólo
teníamos el BDE por lo que no era necesario tomar ninguna decisión sobre la
tecnología de acceso a datos que debíamos utilizar. En Delphi 7 las cosas son muy



www.danysoft.com - Página 4/9

Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de Datos con Delphi

distintas ya que tenemos cuatro alternativas de acceso a datos: BDE, dbExpress, ADO
e IBExpress. Y no sólo eso. Cada vez es más común enfrentarnos a situaciones en las
cuales nuestra aplicación debe trabajar indistintamente con Paradox, InterBase y
Oracle, por nombrar sólo tres fuentes de datos. En este escenario quizás lo ideal sería
utilizar BDE para Paradox, IBExpress para InterBase y DOA (Direct Oracle Access)
para Oracle.
La capa de abstracción que implica el uso de los componentes ClientDataSet y
DataSetProvider nos permiten resolver este tipo de situaciones obteniendo al mismo
tiempo y por el mismo precio ventajas adicionales.

Un módulo de datos para cada cosa

Normalmente no colocamos los componentes de acceso a datos en formularios sino en
módulos de datos. De esta manera separamos la lógica de datos de la lógica visual. En
todos los casos, la lógica visual debería estar condicionada siempre por la lógica de
datos y nunca al revés. Es decir, el formulario debe saber de la existencia del módulo
de datos pero el módulo de datos no debe saber de la existencia del formulario. Este
es un principio básico que deberíamos seguir a la hora de desarrollar aplicaciones de
bases de datos con Delphi. Para ponerlo más claro.

La unidad del módulo de datos debe ser incluida en la cláusula uses de la
unidad del formulario pero la unidad del formulario nunca debería ser incluida
en la cláusula uses de la unidad del módulo de datos.

Es posible que para cumplir este principio básico debamos programar un poco más
pero es un esfuerzo que bien vale la pena hacer. Veamos un caso como ejemplo.
Supongamos que un proceso de un módulo de datos depende del valor de un
CheckBox de un formulario para realiza una u otra acción. La tentación de añadir la
unidad del formulario a la cláusula uses de la unidad del módulo de datos y utilizar
directamente el CheckBox es muy grande pero no debemos hacerlo nunca. En su
lugar podríamos añadir una propiedad a la clase del módulo de datos y cada vez que
cambia el valor del CheckBox del formulario modificar la propiedad del módulo de
datos. Luego, en el proceso del módulo de datos deberíamos utilizar dicha propiedad
en lugar del CheckBox del formulario.
Siguiendo este principio, cuando utilizamos los componentes ClientDataSet y
DataSetProvider deberíamos utilizar un módulo de datos para los componentes de
acceso a datos y otro para los componentes de lógica de datos, como lo muestran las
siguientes imágenes de pantalla.



www.danysoft.com - Página 5/9

Guías Técnicas Grupo Danysoft: Aplicaciones de Bases de datos con Delphi



Es más, hasta sería conveniente utilizar un tercer módulo de datos para el componente
de conexión (en este caso el Database1) ya que generalmente sólo necesitamos un
componente de conexión para toda la aplicación.
Todo lo relacionado con lógica de datos deberíamos codificarlo en el módulo de datos
"Logica_De_Datos". Aquí podríamos crear campos persistentes para el ClientDataSet
y configurar sus propiedades y escribir código para sus eventos. También podríamos
personalizar el proceso de actualización y reconciliación de errores por medio de las
propiedades y eventos tanto del DataSetProvider como del ClientDataSet.
Todo lo relacionado con acceso a la fuente de datos deberíamos codificarlo en el
módulo de datos "Acceso_A_Datos_BDE_DBDemos". Quizás sea un nombre
demasiado largo para un módulo de datos pero mi idea es reflejar claramente que se
trata de un módulo de datos que nos provee acceso al alias DBDemos del BDE. En
lugar de "Acceso_A_Datos_" podría haber escrito "Country_" y haber creado otro
módulo de datos llamado "Country_IBExpress_DBDemos.GDB" para acceder a la
misma tabla pero en la base de datos DBDemos.GDB por medio de los componentes
IBExpress. Luego, para acceder a una u otra fuente de datos lo único que tendríamos
que modificar es el v