TDataSource - ¿Para qué existe?

[roman]

Decidí colocar esta pregunta en el foro de debates ya que se trata más de una pregunta de concepto que de uso de una componente.

El caso es que estamos acostumbrados a utilizar componentes data-aware para acceder a bases de datos y mecanicamente colocamos un dataset de nuestro gusto, lo conectamos al correspondiente datasource y a éste conectamos las componentes data-aware.

Cada componente data-aware puede conectarse a un sólo datasource y cada datasurce puede conectarse a un solo dataset.

De manera que, ¿por qué las componentes data-aware no se conectan directamente al dataset? ¿Cuál es el papel esencial de este intermediario?

Cierto que puede esgrimirse por lo menos una razón de practicidad: si queremos cambiar el dataset asociado a un juego de componentes data-aware, en lugar de cambiar la hipotética propiedad dataset de cada componente basta cambiar la propiedad DataSet del DataSource.

Pero ¿es ésta la razón de fondo?

¿Qué piensan ustedes?

// Saludos

[jachguate]

Me parece que, aparte de lo ya mencionado, la mayor ventaja de tener un DataSource es la habilidad para habilitar/deshabilitar los controles asociados DataSet agrupandolos de la manera que te convenga.

Tenes un control bastante granular, puesto que podes tener varios datasources asociados a un solo dataset, dependiendo de la funcionalidad que busques. Y los diferentes controles db-aware asociados a uno u otro DataSource.

No se me ocurre ahora un ejemplo práctico, pero en el campo de batalla me he valido de esto mas de una vez.

Otra característica que me parece importante, en un diseño con Módulos de datos, es la capacidad de añadir ciertos eventos que se ejecuten globalmente para el datasource, sin tener que asociarlos a los eventos del dataset. Eventos como OnDataChange, OnStateChange y OnUpdateData, son ideales para llevar a cabo tareas típicas de la interacción con el usuario, sin dejar vínculos entre tu DataModule (capa de acceso/manejo de datos) y el FrontEnd.

Hasta luego.

[delphi.com.ar]

Siempre tuve la idea que el TDataSource es el "comunicador" de los componentes visuales con un set de resultados. Digamos que los TDataSet funcionan simplemente como un set de resultados, y tienen toda la funcionalidad para filtrar, modificar pero carece de funcionalidad para ser utilizados contra controles que se actuelicen automáticamente... los TDataSource tienen la funcionalidad para que los componente dbaware se actualicen automáticamente cuando cambia los datos o el estado del DataSet.
Si quieres desarrollar una aplicación que consulta datos, pero sin interfaz gráfica, prescindes de los TDataSource´s

Saludos!

[__marcsc]

Empezado por delphi.com.ar

Siempre tuve la idea que el TDataSource es el "comunicador" de los componentes visuales con un set de resultados. Digamos que los TDataSet funcionan simplemente como un set de resultados, y tienen toda la funcionalidad para filtrar, modificar pero carece de funcionalidad para ser utilizados contra controles que se actuelicen automáticamente... los TDataSource tienen la funcionalidad para que los componente dbaware se actualicen automáticamente cuando cambia los datos o el estado del DataSet.
Si quieres desarrollar una aplicación que consulta datos, pero sin interfaz gráfica, prescindes de los TDataSource´s

Saludos!

Eso que dices es cierto, pero debido a cuestiones diseño... Es decir, son consecuencias directas del diseño de clases de Delphi más que razones por si mismas...

Básicamente estoy con Juan Antonio, la mayor utilidad de un DataSource desde el punto de vista teórico es el mayor control sobre los controles, y los eventos que proporcionan, que permiten más versatilidad que si tuvieramos que asociarlos directamente a un DataSet. Por otra parte creo que a la práctica lo más interesante es lo que comenta roman de que

Empezado por roman

si queremos cambiar el dataset asociado a un juego de componentes data-aware, en lugar de cambiar la hipotética propiedad dataset de cada componente basta cambiar la propiedad DataSet del DataSource.

La verdad es que por ejemplo en QuickReport, que prescinden de ellos, los echo de menos

Saludos!

[delphi.com.ar]

Empezado por marcsc

La verdad es que por ejemplo en QuickReport...

Porque no necesita reflejar los cambios en el momento!!!... solo requiere en un momento el DataSet que es cuando se arma el reporte!

[__marcsc]

Empezado por delphi.com.ar

Porque no necesita reflejar los cambios en el momento!!!... solo requiere en un momento el DataSet que es cuando se arma el reporte!

Sisi, solo intentaba relacionarlo con lo que decía roman de que es más práctico a la hora de hacer cambios, si en un report tienes que cambiar el origen de datos tienes más trabajo que si los reports tuvieran DataSource, ya que solo tendríamos que cambiar el DataSet en el DataSource y no en todos los componentes.

Saludos!

[jachguate]

Hablando de QuickReporte, aunque es quizas algo retorcido al principio, además de lo ya mencionado, podria tener sentido "ocultar" datos de algun reporte simplemente desactivando un DataSource, no?

Algo como

Código Delphi [-]
  dsDatosGerenciales.Enabled := esGerente;
  dsCostos.Enabled := esContabilidad or esGerente;

Asi, en un hipotético reporte, asocias las columna [CostoUnitario] y [CostoReposicion] al DataSource dsCostos,
las columna [utilidadbruta], [CostoFinanciero] al datasource dsDatosGerenciales

y el resto de columnas al datasource dsDatos.

Tendrias casi gratuitamente informes mucho mas dinámicos...

Hasta luego.