Das gäbe natürlich Probleme. Die letzte Änderung würde sich durchsetzen.
Man kann/müsste sich hier überlegen, wie man eine Art abgespeckte Transaktionsverwaltung regeln könnte.
Zumindest müsste es eine Sperre für bestimmte Konflikte geben.
Im Moment wollte ich erst mal an die gezeigte Stelle kommen und das hat ganz gut funktioniert.
Die gesamte Projektlogik läuft im "SchoolManager" und die
GUI im Client bekommt zur Designtime oder Laufzeit lediglich eine ObjektId und ggf. ObjektyProperty zugewiesen.
Eine 08/15-Datenbankanwendung soll mein Ansatz nicht ersetzen, ich möchte aber z.B. mein Turnierprojekt gern auf C/S umstellen und suche dafür Möglichkeiten.
Ich habe auch schon einen
DB-Einsatz getestet aber das hat nicht wirklich funktioniert. Dafür die die Projektstruktur einfach zu komplex und variabel.
Daher will ich mit Objekten arbeiten. Auch die
GUI soll die Daten in "Objekten" präsentieren, so dass der User die Spieler, Spiele, Felder usw. anfassen und verschieben kann.
Grids will ich vermeiden und deshalb ist auch DataBinding und DataSnap nichts passendes für mich.
Die Arbeitsweise, in den Client-Controls letztlich nur die PropertyNames einzutragen und den Rest dem Framework (sind hier letztlich nur 2 Units und die Controls) zu überlassen, hat sich für mich jedenfalls in meinem bisherigen Projekt schon sehr bewährt.
Die
GUI-Controls fordern (wenn sie sich zeichnen müssen) eigenständig die benötigten Objekte bei ClientManager ab. Der ClientManager holt die Objekte vom Server. Falls von dort neuere Daten kommen, weist er das Control (bzw. dessen Controller) an, sich nochmal mit den neuen Daten zu zeichnen.
Natürlich fehlt da noch jede Menge (auch eine Eingabevalidierung), aber ich wollte Euch dennoch mal das erste Ergebnis zeigen und Eure Einschätzungen dazu hören.