I know this is not what you asked, but I will share my experience with you. My biggest problem with legacy code in database applications is that the main logic of it is dataset-dependent.
When I faced the very same problem you do now (I was going to replace TQuery
and TwwQuery
by TADOQuery
) I decided to stop my dependence of TxxxQuery and become dependent on TClientDataset
(CDS). I found CDS a much better dataset to work with, It has some features you won´t find in other datasets, like aggregate fields, for instance. With CDS you can load new records on demand without selecting all the rows again and you have TDatasetField
as another way of handling master-detail relationships. To me it was more than enough.
Besides, the particular database access dataset stays behind TDatasetProvider
component. Your main logic will be dependent on CDS only, not TADOQuery
, TODACQuery
or any other TxxxQuery that you may need in the future. That was the last time I had to worry about this issue. If I have to replace my datasets, it won´t affect the critical business logic anymore, only persistence logic (which I moved to another DataModule)!
So, I planed all my evolution strategy to move from TQuery
and TwwQuery
to TClientDataset
as the first step and then replaced TQuery
and TwwQuery
by TADOQuery
as a second step.
I didn´t use any helpers to refactor the code. It was indeed a lot of work but it had to happen only once and for all.
Nowadays I have replaced the middleware datasets (TQuery
, TwwQuery
, TADOQuery
, etc) by a persistence service that is able to run a query and return an OleVariant
with the records found. All I have to do is to assign this OleVariant
to the TClientDataset.Data
property and it´s done!
No more dependence of any kind of dataset in the application´s code, except for CDS!