GUI-Anwendung - Strukturierung des Programms

[hkl]

Um das vll noch mal abstrahiert darzustellen: Wie strukturiere ich GUI und den Programmkern, bzw. wie verknüpfe ich beide am besten?

Wenn Du eine normale Anwendung schreibst, also nicht mit Spezialsoftware hantierst, dann machst Du am besten folgendes:
1.) die DB designen
2.) den Datenzugriff (SQL) entweder als so genannte stored procedure im RDBMS ablegen oder modularisiert (d.h. absolut vom UI-Code getrennt) im Code (Ersteres ist vorzuziehen)
Dann hast Du das System geschrieben, d.h. alles, was Deine Anwendung können soll, kann Sie schon. Aber nur "per Hand" im Query-Tool Deines RDBMS. das reicht uns noch nicht, also:
3.) UI-Code schreiben, schön modularisiert und zwar "parallel" zum Datenzugriffscode. Also ich meine so "1:1", ach ich weiss jetzt auch nicht wie ichs schreiben soll.   ;)

Hallo Hamstar !

Glaube zu vertehen wie Du's meinst, aber kann man nicht die "Welten" mittels einer Singleton-Fassade voneinander trennen ?

DIE koennte man dann so prozedural odr OO-like skalieren wie man's grade braucht.

Sowas wie "Fenster", "Rahmen", oder "Document" und "View"  finde ich praedstiniert fuer einen OO-Ansatz;  Gamma et al. geben ja sogar einen WYSIWYG-Editor als Fallstudie.

Den Bruch zwischen OO und RDBMS kann man doch mittels DAO ( allgemein; nicht das was MS ausliefert ) oder halt einem threadsicheren Single Access Point ( Singleton::getInstance() ) kaschieren, oder ?

Nur von 1:1 Modell/Form ( wie bei MS - Recordset Forms ) ist, denke ich, Abstand zu nehmen.
Wenn, dann sollte man SPs OO-klammern, oder ?

Gruesse

Holger

Es gibt objektorientierte Ansätze fürs UI, aber ich lass davon die Finger weil sich m.E. eine "normale" Anwendung (viele Transaktionen aufs RDBMS) mit Objektorientiertheit beisst.

Aber "it depends", schreibst Du Grafikprogramme oder Editoren oder Tabellenkalkulationen, also Anwendungen die "UI-komplex" sind, dann kommst Du am Verständnis dessen was Franky so geschrieben hat, nicht vorbei. Viel Spass!   ;)