Visual inheritance of DB components or New component?

Question

I have 3 different DataModules: ADOModule, SDACModule, AstaModule. All are identical, except DB components they use: ADO, SDAC, Asta.

All these DataModules do the same job, but through the different components. What I mean - is that all inner selects and execs are the same.

What I search for: is a method to combine all of this DataModules to one BaseDataModule, and force each of ADOModule, SDACModule and AstaModule to inherit from BaseDataModule.

Well, I find it easy to inherit methods and properties, but I've never used to inherit from components. Is there any nice way to do so? Project goal: minimize coding and copy-pasting.

Answer 1

There are several options available to you but the approach I would take would be as follows :-

1. Create an abstract base class for your Database and Query components. Your base class should define all the methods and properties you're going to need.

2. Create concrete descendants for each data access layer that are effectively wrappers around the underlying data-access layer.

3. Move the current data module code into a non-visual unit that references the abstract component type instead of any specific type of access layer.

4. You can now easily switch between access layers or even add new ones in the future.

This is a classic example of the Adapter (or Wrapper) pattern.

If you'd rather not re-invent the wheel, you might want to consider looking at an OPF/ORM solution like tiOPF, InstantObjects or TMS Aurelius which will give you the same functionality and a lot more besides.

Answer 2

Allow me to suggest a different path. I recommend you to write your DataModules all based in TClientDataset instead any other specific datasets. Add all the properties and methods needed, always working with TClientDataset instances.

Then create a data access service interface, let say IDataProvider, that provides methods to select data and execute SQL statements. The select method will receive the query text and return an OleVariant that will be holding all the records found (the Data property of an internal TClientDataset). This OleVariant, when assigned to the Data property of a TClientDataset instance on a DataModule will populate it.

Finally, write implementation classes to IDataProvider. Those classes will dependent on the specific data access technologies you need to support.

This architecture will make your application completely independent of data access method. In the future, if you need a fourth way to get your data, you will just have to add a new implementation of IDataProvider and all the rest will continue to work.

If you put those implementation classes in separated packages, you will be able to dinamically set your application to work with different data access methods, by dinamicaly loading those packages, without having to even recompile your application. Think about how nice that is!