Why was TDataSource created originally?

Question

What was (or would be) the reasoning behind creating TDataSource as an intermediary between data bound components and the actual underlying TDataSets, rather than having the components just connect directly to the TDataSets themselves?

This may seem like kind of a stupid question, but I am working on a broad set of "data viewer" components, which link to a common "data connector" component, etc; and in designing this set of components, I find myself referencing the structure of the classic Delphi "TDataSet -> TDataSource -> Data-bound-component" setup for guidance. In my component set, however, I keep wanting to essentially merge the functionality of the "TDataSource" and "TDataSet" equivalents into a single class. It got me wondering what the reasoning was behind separating them in the first place.

Answer 1

I don't know if this is exactly what the dev team was thinking, but one way it might be helpful is for changing data sets. Let's say you have a whole bunch of data-aware controls, and they're all bound to one dataset, and then you want to change over to a different one. If they're all bound through an intermediary, all you have to do is change the datasource's .Dataset property instead of iterating over all the controls and changing their properties.

(Though you might still have to change a bunch of field names, depending on how things are set up, so this might not be the best possible example.)

Answer 2

I think so that data aware controls can be attached to different datasets, by just changing the dataset their associated datasource points to rather than having to change each control's dataset.

So, you could change which database you are using just by changing a single datasource instead of loads of TDBEdits, TDBGrids etc.

Answer 3

• TDataSet is about accessing the database.
• TDataSource is about user interfaces: Disabling/enabling, synchronizing, data flow etc.

If you combine these two, your database component gets a dependency to the specific user interface infrastructure, that you are using. These kinds of dependencies can be ok in your own program, but not ok in an API that is distributed to a lot of developers.

Answer 4

You can think about it as some sort of Model-View-Controller pattern.

The data are located in the DataSet (the model) that does not know anything of who is using them and for what.
The DB aware components provide different interfaces (the views) for the user to interact with these data without knowing who holds them.
The DataSource is the go between (the controller) that provide the linkage and dispatch any data change or command to either the model or the views.

This allows an easy binding to a different dataset without touching the views, or changing or adding new views without the dataset having to care about them.

Answer 5

It is all about decoupling and indirection.

And with TDataSource there are two kinds of them:

• Decoupling the master detail relations (TDataSource is in the same module as the TDataSets that are being bound; the detail TDataSet references the master TDataSet by pointing its' MasterSource property to the TDataSource that points to the master TDataSet)
• Decoupling the UI from the business layer (TDataSets are in a DataModule; TDataSource is on the Form/Frame which contains your UI controls, UI controls reference their DataSource property).

Since many components can point to the same DataSource, you can quickly switch which underlying TDataSet they use by just flipping one TDataSource.DataSet property.