Perché TDataSource è stato creato originariamente?

Question

Qual è stato (o sarebbe) il ragionamento alla base della creazione di TDataSource come intermediario tra i componenti associati ai dati e gli attuali TDataSet sottostanti, piuttosto che avere i componenti semplicemente connessi direttamente ai TDataSet stessi?

Potrebbe sembrare una specie di domanda stupida, ma sto lavorando a una vasta gamma di "visualizzatore di dati" componenti, che si collegano a un comune "connettore dati" componente, ecc .; e nel progettare questo insieme di componenti, mi ritrovo a fare riferimento alla struttura del classico Delphi "TDataSet - > TDataSource - > Data-bound-componente " installazione per orientamento. Nel mio set di componenti, tuttavia, continuo a voler fondere essenzialmente la funzionalità di "TDataSource" e "TDataSet" equivalenti in una singola classe. Mi ha fatto chiedermi quale fosse il ragionamento dietro a separarli in primo luogo.

Answer 1

Si tratta di disaccoppiamento e indirection .

E con TDataSource ce ne sono due tipi:

• Disaccoppiamento delle relazioni di dettaglio principali (TDataSource si trova nello stesso modulo dei TDataSet che vengono associati; il dettaglio TDataSet fa riferimento al TDataSet principale indicando ' proprietà MasterSource alla TDataSource che punta al TDataSet principale)
• Disaccoppiamento dell'interfaccia utente dal livello aziendale (i TDataSet sono in un DataModule; TDataSource si trova nel modulo / frame che contiene i controlli dell'interfaccia utente, i controlli dell'interfaccia utente fanno riferimento a proprietà DataSource ).

Poiché molti componenti possono puntare allo stesso DataSource, puoi cambiare rapidamente quale TDataSet sottostante usano semplicemente lanciando una proprietà TDataSource.DataSet.

Answer 2

Penso che i controlli sensibili ai dati possano essere collegati a diversi set di dati, semplicemente cambiando il set di dati in cui puntano i loro punti di origine associati anziché dover cambiare il set di dati di ciascun controllo.

Quindi, puoi cambiare il database che stai usando semplicemente cambiando una singola origine dati invece di carichi di TDBEdits, TDBGrids ecc.

Answer 3

• TDataSet riguarda l'accesso al database.
• TDataSource riguarda le interfacce utente: disabilitazione / abilitazione, sincronizzazione, flusso di dati ecc.

Se si combinano questi due, il componente del database ottiene una dipendenza dalla specifica infrastruttura dell'interfaccia utente che si sta utilizzando. Questo tipo di dipendenze può essere ok nel tuo programma, ma non ok in un'API che è distribuita a molti sviluppatori.

Answer 4

Puoi pensarlo come una sorta di modello Model-View-Controller.

I dati si trovano nel DataSet (il modello) che non sa nulla di chi li sta usando e per cosa.
I componenti che riconoscono il DB forniscono diverse interfacce (le viste) affinché l'utente possa interagire con questi dati senza sapere chi li detiene.
DataSource è la via di mezzo (il controller) che fornisce il collegamento e invia qualsiasi modifica o comando di dati al modello o alle viste.

Ciò consente di associare facilmente un set di dati diverso senza toccare le viste o modificare o aggiungere nuove viste senza che il set di dati debba occuparsene.

Answer 5

Non so se questo è esattamente quello che stava pensando il team di sviluppo, ma un modo in cui potrebbe essere utile è cambiare i set di dati. Supponiamo che tu abbia un sacco di controlli sensibili ai dati e che siano tutti associati a un set di dati e quindi desideri passare a uno diverso. Se sono tutti associati tramite un intermediario, tutto ciò che devi fare è cambiare la proprietà .Dataset dell'origine dati invece di iterare su tutti i controlli e cambiarne le proprietà.

(Anche se potresti dover cambiare un sacco di nomi di campi, a seconda di come sono impostate le cose, quindi questo potrebbe non essere il miglior esempio possibile.)