¿Por qué se creó TDataSource originalmente?

Question

¿Cuál fue (o debería ser) el razonamiento detrás de la creación de TDataSource como intermediario entre los componentes vinculados a datos y los TDataSets subyacentes reales, en lugar de tener los componentes solo para conectarse directamente con los TDataSets mismos?

Esto puede parecer una pregunta estúpida, pero estoy trabajando en un amplio conjunto de componentes de "visor de datos", que se vinculan a un componente común de "conector de datos", etc .; y al diseñar este conjunto de componentes, me encuentro haciendo referencia a la estructura de la configuración clásica Delphi "TDataSet -> TDataSource -> Data-bound-component" para obtener orientación. En mi conjunto de componentes, sin embargo, sigo queriendo esencialmente fusionar la funcionalidad de los equivalentes "TDataSource" y "TDataSet" en una sola clase. Me hizo preguntarme cuál era el razonamiento detrás de separarlos en primer lugar.

Answer 1

Todo es acerca de decoupling y indirection.

Y con TDataSource hay dos tipos de ellos:

• desacoplar la relación maestro detalle (TDataSource está en el mismo módulo que los TDataSets que están siendo atados; el detalle TDataSet hace referencia a la TDataSet maestro señalando su 'MasterSource alojamiento hasta el TDataSource que apunta a la TDataSet maestro)
• Desacoplamiento la interfaz de usuario de la capa de negocio (TDataSets están en un módulo de datos; TDataSource está en el Formulario/marco que contiene los controles de interfaz de usuario, hacen referencia a los controles de interfaz de usuario de su propiedad DataSource) .

Dado que muchos componentes pueden apuntar al mismo DataSource, puede cambiar rápidamente qué TDataSet subyacente usan simplemente volteando una propiedad TDataSource.DataSet.

Answer 2

No sé si esto es exactamente lo que el equipo de desarrollo estaba pensando, pero una forma en que podría ser útil es cambiar los conjuntos de datos. Digamos que tiene un montón de controles de datos, y todos están vinculados a un conjunto de datos, y luego desea cambiar a uno diferente. Si todos están enlazados a través de un intermediario, todo lo que tiene que hacer es cambiar la propiedad .Dataset de la fuente de datos en lugar de iterar sobre todos los controles y cambiar sus propiedades.

(Aunque es posible que aún tiene que cambiar un montón de nombres de campo, dependiendo de cómo las cosas se crean, por lo que este podría no ser el mejor ejemplo posible.)

Answer 3

creo para que los datos controles conscientes pueden ser adjunto a diferentes conjuntos de datos, simplemente cambiando el conjunto de datos de sus puntos de origen de datos asociados en lugar de tener que cambiar el conjunto de datos de cada control.

Por lo tanto, se puede cambiar qué base de datos que está utilizando simplemente cambiando una sola fuente de datos en lugar de un montón de TDBEdits, etc. TDBGrids

Answer 4

• TDataSet se trata de acceder a la base de datos.
• TDataSource se trata de interfaces de usuario: activar/desactivar, de sincronización, el flujo de datos, etc.

Si se combinan estos dos, el componente de base de datos para crear una dependencia de la infraestructura de interfaz de usuario específico, que está utilizando. Este tipo de dependencias puede estar bien en su propio programa, pero no está bien en una API que se distribuye a muchos desarrolladores.

Answer 5

Puede pensarlo como un tipo de patrón Modelo-Vista-Controlador.

Los datos se encuentran en el DataSet (el modelo) que no sabe nada de quién los está utilizando y para qué.
Los componentes de DB aware proporcionan diferentes interfaces (las vistas) para que el usuario interactúe con estos datos sin saber quién los tiene.
El DataSource es el intermedio (el controlador) que proporciona el enlace y envía cualquier cambio de datos o comando al modelo o a las vistas.

Esto permite un enlace fácil a un conjunto de datos diferente sin tocar las vistas, o cambiar o agregar nuevas vistas sin que el conjunto de datos tenga que preocuparse por ellas.