Първо благодаря за отговора.

Значи, нещата са много дълги и сложни и заплетени, и предполагам, че ще отегча хората...

Първо аз излъгах малко (за да не обяснявам на дълго и широко), за TIBDataSet. Всъщност тоя Wrapper class ми е необходим само за да мога по лесно да ползвам DB aware контроли. Ако TDataSource беше направен така че да може да се наследи щях да ползвам него но уви... Т.е. идеята ми (от която вече се отказах) беше wrapper-а да си взима данните от каквото и да е (не непременно от друг TDataSet)...

Системата е нещо като ERP. Имам ApplicationServer който не се връзва директно към Database а между тях има оше един layer който аз наричам Storage (TStorage да речем). AppServer-a очаква TStorage, или наследник на TStorage от който да взима данните (по установен протокол - серия от методи и т.н.). Самият TStorage не е много ясно от къде взима данните - той е базов абстрактен клас, неговите наследници взимат данни от някъде [TextFile..SQLServer]. Причината да ползвам междинен layer между AppSrv и DB е че системата не трябва да зависи от Phisical Storage или от точно определен вид бази данни. Пример: мода да имам TIBStorage, TMSSQLServerStorage, TOracleStorate, TMySQLStorage, TXMLStorage, TCSVStorage и т.н... Конкретния Storage стои в .bpl (package) и се зарежда според конфигурацията. TStorage има възможността да записва обекти "директно" (обектите който ползва AppServer) и разни други неща.

Пример за Storage:
-----------------------------------
TStorage = class;
TSQLStorage = class(TStorage);
TFIBStorage = class(TSQLStorage);
TFIBPlusStorage = class(TFIBStorage);

TStorage (Знае как да записва обектите) <
< TSQLStorage (добавя функционанност за запис в ANSI99 SQL Server) <
< TFIBStorage (съобразен със спецификите при Interbase,Firebird) <
< TFIBPlusStorage (конкретна имплементация с помоща на FIBPlus компонентите);
-----------------------------------

"API"-то на TStorage наподобява DBVCL в много отношения, но и в много се различава. Щеше ми се (понеже съм мързелив) да направя наследник на TDataSet към който да връзвам DB контроли, а той да си взима данните от Storage-a, но се отказах защото разликите се оказаха повече от приликите. Например навигацията при TDataSet (или изобщо при базите данни) запис напред, запис назад (first,next,prior...) не се връзва с навигацията в моята система (която е по скоро като да се разхождаш по "дърво")... абе беше доста тъпа идея. После мислех за TDataSetProvider което пак се оказа тъпа идея. И сега правя нещо като DataSource който да взима данни от Storage и да ги слага във визуални контроли. Нещо като mapper, binder...

Това е много накратко казано, но ме мързи да пиша защото е много (особено за сървъра, клиентите, връзката между тях и т.н.)

Това което казваш, че да правиш такива неща при обектно ориантираното програмиране е "анатема" е абсолюто вярно. Аз обаче понякога го правя с цел оптимизация или ако класа(овете) от които наследявам не са измеслени много добре (или поне на мен не ми се връзват с идеологията). Има и нещо друго - мързел:)