Also meine
DC´s haben unterschiedliche Eigenschaften und Methoden.
Das ist normal. Absolut normal.
Zitat:
Ein Spieler hat einen Vornamen und Namen und kann einen FullName "berechnen".
Eine Mannschaft hat selbst einen Namen und kann 0..n Spieler beinhalten.
Gut!
Zitat:
Es gibt also Einfache
DC und Listen-
DC.
Joa... ==> Aggregierende Objekte. Deine Klassifizierung ist etwas merkwürdig und führt leicht in falsche Denkstrukturen, aber vom Prinzip her OK.
Zitat:
Jede
DC besitzt einen
XML-Knoten, über den die Daten verwaltet werden.
Das könnte man entkoppeln, was etwas schöner wäre. Aber auch das ist noch OK. Kann man so machen.
Zitat:
Die Datenschicht (Funktionen, die die
DC zum Lesen und schreiben verwenden) setzen alle SC's (die bis zu ihrer Auflösung in einer Liste gesammelt werden) auf Invalidate;
Peng! Kapitalfehler. Genau *das* dürfen Schichten nämlich nicht. Eine untere Schicht darf *niemals* auf eine höhere zugreifen. Genau das heißt nämlich "Schicht". Eine Anwendung, die in Schichten organisiert ist, ist immer hierarchisch. Die unteren Schichten wissen gar nicht, dass es die oberen gibt. Und erst recht ändern sie da nix. Es passiert immer umgekehrt: Die oberen Schichten benutzen die unteren.
Was aber, wenn die oberen darauf reagieren müssen, wenn auf den unteren Schichten was passiert? Dafür gibt es Indirektionsmechanismen. Also Events oder beispielsweise das Observer-Pattern.
Zitat:
Diese werden also bei Gelegenheit neu gezeichnet und holen sich dabei die aktuellen Werte aus "ihren"
XML-Knoten.
OK.
Zitat:
Die Listenkomponenten aktualisieren dabei auch ihre Items, erzeugen neue (bei neuen Datensätzen) oder löschen überzählige (bei gelöschten Datensätzen).
Auch OK.
Zitat:
Windows kann aber in diesen Fällen auch mal ein Item (abgeleitet von TPanel) neu zeichnen wollen, bevor die übergeordnete Listenkomponente sie gelöscht hat.
Die Controls sind ja eigentlich unabhängig voneinander.
Ganz böse. Du hast hier eine Abhängigkeit erzeugt, die dir sehr lustige Probleme bereiten kann.
Zitat:
Und das Problem löse ich über das Auflösen des Daten-Zeigers einer SC, wenn dessen
DC nicht mehr gülig ist.
Jein. Du löst das Problem nicht, du umgehst es. Du klebst notdürftig einen Flicken drauf. Das Problem ist, dass du Invalidate für etwas verwendest, für das es nicht gedacht ist. Invalidate sagt nur "zeichne dich neu", nicht aber "es gibt neue Daten". Du verpasst dem eine neue Semantik und das ist gefährlich. Dadurch kriegst du Abhängigkeiten, die sich auf die Nebenläufigkeit auswirken. Du reparierst das Ganze, indem du die nebenläufigen Fälle separat behandelst. Das setzt voraus, dass du wirklich alle bedenkst. Deine Software wird, wenn sie wächst, ggf. neue nebenläufige Ausführungspfade haben, die du alle bedenken musst. Und wie Murphy so will, wirst du vermutlich irgendwann einen dieser Fälle nicht bedenken und du hast nen extrem schwer zu findenden Bug. Oder zwei. Oder drei. Oder mehr. So Konstruktionen sind gefährlich und tendenziell Bugschleudern.
Zitat:
Grundsätzlich werden immer nur sichtbare Bereiche aktualisiert, wenn Änderungen in der Datenschicht erfolgt sind.
"Premature optimization is the root of all evil in programming." -- Donald Knuth (wohl Hoare zitierend)
mfg
Christian