Klar, kann man so machen.
Habe da mal 'ne eigene Klasse, abgeleitet von einer Datenbankkomponente gemacht. Die Klasse hatte u. a. die Attribute InsertID, UpdateID, DeleteID und SelectID. Dort stand dann die entsprechende ID.
Dann gab es die passenden Methoden dazu.
Von dieser Klasse waren dann die weiteren Klassen für Kunden ... abgeleitet. Sie hatten zusätzlich dann die entsprechend Attribute wie Name ...
Als Programmiere musste man für's Select dann nur noch die Get-Methode aufrufen. Für neue Daten halt New, Update ging über Set und Delete setzte nur einen Löschschalter und Löschdatum ... im Datensatz, da keine Daten physikalisch aus der Datenbank entfernt wurden.
Eigentlich war das für den Entwickler sehr transparent.
Er musste sich weder um die Zuweisung der Tabelleninhalte in die Attribute kümmern, noch um den umgekehrten Weg.
Das Einzige, was er machen musste, war: Die Inhalte der Attribute in die Anzeigemaske bringen bzw. die Inhalte der Anzeigemaske wieder in die Attribute der Klasse schieben.
Dafür waren die passenden Getter und Setter angelegt.
Und er musste natürlich, soweit erforderlich, die entsprechende Geschäftslogik und ggfls. Plausibilitätsprüfungen ..., implementieren.
Die Basisklasse war schon recht kompliziert und funktionierte zum Teil über
RTTI, aber die Benutzung im Programm war dann beinahe schon banal einfach.
Schon interessant, was man mit
RTTI und sinnvoller Vererbung für "schöne Schweinereien" machen kann. Da sieht man dann, wie leistungsfähig einen vernünftige Objektorientierung sein kann.