Bei einem unserer Projekte (~500.000 Zeilen) machen wir das genau so wie du als letztes beschrieben hast.
Je eine Klasse pro Entität. Diese enthalt drei Konstruktoren. Einen für einen neuen Datensatz, einen dem eine Datensatz-ID übergeben wird und einen, dem ein DataSet übergeben wird. Den dritten benötigen wir für unsere Listenklassen. Diese fahren eine beliebige
Query und erzeugen für jeden Satz im Resultset ein Datenobjekt, dass sie in eine interne Objektlist packen.
Die
GUI greift (meist
) ausschließlich auf die Datenklassen zurück. Ausnahmen bilden bei uns eigentlich nur Suchabfragen, da diese durch den zusätzlichen Umwandlungsschritt nicht gerade schneller werden.
Den Datenbankzugriff machen wir derzeit direkt. Du müsstest wenn du generisch bleiben möchtest, halt nur Datasets weitergeben und die Queries beispielsweise über eine eigene
Query laufen lassen, die von einer konkreten erbt. Ich würde allerdings immer bei Dataset kompatiblen
DB Zugriffsarten bleiben.
Bei einem neueren Projekt gehen wir einen leicht modifizierten Weg, indem die Datenklassen eine Collection der Felder enthalten und somit die
SQL Statements für die Std-Aktionen selbst erzeugen kann. Im Grunde arbeiten wir mit einer Art selbstentwickelten OR Mapper.
Aber egal wie du es auch machst, hinterher fallen dir immer hundert Sachen ein, die du beim nächsten Projekt anders machen möchtest.