@Luckie
Das ist richtig. So rum (
GUI meldet Controls an) oder so rum (
GUI meldet Ereignisse an) ist eigentlich relativ egal.
Wesentlich ist, dass sich die
GUI erst zur Laufzeit bei der Datenebene anmeldet und von dort über Änderungen informiert wird.
Ich selbst weise meinen Controls nur die gewünschten Eigenschaftsnamen als Text zu (z.B. "Tournament.Sport.DisciplineList[3].Name"). Zur Laufzeit wird dann per
RTTI das vierte Item einer DisciplineList z.B. einem Edit zugewiesen und dessen Property Name dort zu Bearbeitung dargestellt.
Die Datenebene braucht dann überhaupt nix von einer
GUI zu wissen. Sie informiert lediglich ganz allgemein, wenn es etwas neues gibt und meine Controls suchen sich dann die passenden Objekte und Propertys "automatisch" zur Anzeige und ggf. Bearbeitung heraus.
Das setzt voraus, dass die Datenobjekte und sichtbaren Controls aufeinander abgestimmt sind, aber das lässt sich durch kleine Erweiterungen von Standardcontrols realisieren.
Das o.g. "data binding" von Stevie ist eine allgemeinere Lösung (analog zum .NET), die nicht eine bestimmte Datenbasis voraussetzt.
@Jumpy
Die Geschäfts-und Datenebene sollte eben vollständig autonom sein. In meinem Fall bilde ich alles in Objekten ab, die wiederum Objekte enthalten. Die Datenmengen halten sich in Grenzen, dadurch geht das. Durch Getter und Setter und Methoden können komplexe Vorgänge gut abgebildet werden. Wenn in den Daten Änderungen erfolgt sind, gibt es eine Info an die
GUI, wodurch sich alle Controls neu darstellen. Das ist alles. Ob es eine
GUI gibt und was die mit der Info anstellt, ist der Datenebene wurscht.
Die Daten werden in meinem Fall in einer
XML-ähnlichen Struktur gespeichert und geladen. Aber da kann natürlich grundsätzlich auch eine Datenbank oder Internetverbindung dran hängen.
Aber es ist natürlich erst mal einfacher, wenn ich zur Laufzeit alle Daten im Speicher halten kann.