nicht angemeldet
Mir geht's darum nicht mit DB-Tabellen im GUI rumzufummeln. Diese Tabellen kann man kapseln und in ein Subsystem legen das man tunlichst hinter einer Fassade versteckt.
Grundsätzlich ist das sicherlich eine Idee, aber:
1.) der Aufwand ist beträchtlich
2.) man hält die Objekte in der Datenzugriffsschicht (SQL) und in der Geschäftslogikschicht so zu sagen doppelt
3.) der Nutzen ist zweifelhaft (das Abhängen bspw. des RDBMSs und Anhängen eines anderen) dürfte wohl so oder so schwierig sein
4.) man hantiert natürlich nicht mit Tabellen sondern mit Prozeduren wie SET_CONTRACT, LET_CONTRACT, GET_CONTRACT, LST_CONTRACT oder BIZ_GROUPED_CONTRACTS, also ganz CRUDLig.
und falsche Parameterisierung im Subsystem durch Exceptions / Asserts abfangen - so koennte man erreichen dass die App bei Aenderungen im DB-Design nur geringe Code-Aenderungen erfahren muss.
Ich erreiche das durch Abwärtskompatibilität der SPs.
Das ist etwas schwierig ohne eine (Layer-)Graphik zu beschreiben.
Ich versuch mal ein Schichtenmodell:
|GUI|BizObjects|DataAccess|Data|
LOL