GUI-Anwendung - Strukturierung des Programms

[hkl]

Hallo Hamstar!

Trotz all dieser Fachwörter meine ich so halwegs verstanden zu haben, was Du diskutieren möchtest. Anscheinend die Kapselung des Datenzugriffs. Während ich nicht davor zurückschrecke SPs direkt aus dem Code aufzurufen (bei der Pflege und Weiterentwicklung derselben also die Abwärtskompatibilität der SP-Aufrufe beachten muss) möchtest Du anregen eine zusätzliche Schicht einzuziehen, die den Datenzugriff (bspw. auf ein RDBMS) kapselt, d.h. es werden Objekte wie "Server" oder "DB" aufgebaut und dann deren Prozeduren wie bspw. NewContract() oder NewCustomer() aufgerufen.

Dann ist man flexibler, kann also bspw. das RDBMS abhängen und durch ein anderes ersetzen (mit einem anderen SQL-Dialekt und anderer Parametriesierung der SPs (wenn es überhaupt noch SPs sind)) und muss nur die einzelnen Datenzugriffs-Klassen anpassen.

Ist es das was Du meinst?

So in etwas. Wir hatten das schon mal ( Microsoft-) platformspezifisch andiskutiert.

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.

Im mittleren Layer und im GUI tauchen dann nur noch Objkete auf die auch wirklich etwas "leisten" und nicht nur OOP 1:1 auf SQL abbilden.

Man koennte die DAO-Klassen INNERHALB des DB-Subsystems dann uebrigens recht typarm halten, so ala

std::map<_variant_t>

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.

Das ist etwas schwierig ohne eine (Layer-)Graphik zu beschreiben.

Gruesse

Holger