C/S mit Objekten - Grundsatzfrage

[stahli]

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.

[Sir Rufo]

Ich habe das Gefühl, dass du dich da etwas verrant hast.

Änderungen an Objekten sollten nur dann an den Server und dann an die Clients gesendet werden, wenn die Daten konsistent sind. Du schickst aber jede Teiländerung an die Clients, die ja noch während der Änderung in sich falsch sein kann. Somit bekommt ein Client Daten zu sehen, die unsinnig sein können.

Was DataBinding zwangsweise mit Grids zu schaffen hat, ist mir auch schleierhaft.

Nachvollziehen kann ich den Wunsch der Push-Funktion an alle Clients, wenn sich Daten geändert haben.

Nehmen wir die Schule als Beispiel:

Ein Schüler soll von Klasse A in Klasse B verlegt werden. Somit habe ich Änderungen an 3 Objekten.
Aber erst wenn alle 3 Objekte im Server abgelegt sind, dann haben alle Clients Zugriff auf konsistente Daten (Transaktion) und sollten dann informiert werden und nicht früher.

Sind die Daten bei Client A und B in Bearbeitung, dann ist es zudem sehr verwirrend für die Anwender, wenn sich wie durch Geisterhand die Daten verändern.
Dieses Kollisions-Management (gleichzeitige Änderung von mehreren Stellen am gleichen Datensatz) kann man unterschiedlich implementieren mit mehr oder weniger Aufwand:

• Letzte Änderung gewinnt (gesamtes Objekt)
• Objekt wird zur Bearbeitung exklusiv gesperrt
• Nur die Änderungen der Objekt-Felder werden übertragen (letzte Änderung gewinnt)
• Der Client bekommt die Fremd-Änderungen während der Bearbeitung beim Speichern angezeigt und kann darauf entsprechend reagieren

[stahli]

Mein Video zeigt den aktuellen Stand und die grundsätzliche Arbeitsweise.

Ich möchte die Objekte (Daten und BL) auf dem Server haben und die Clients (GUI) mit möglichst geringem händischen Aufwand an diese Objekte "binden".

Ich möchte nicht "Person(1)" abrufen, und die Edits mit dessen Eigenschaften verdrahten.
Ich möchte nur sagen, was die Controls anzeigen sollen, die Daten sollen sie sich selbst beschaffen.

Wenn man LiveBinding oder DSharp nutzt, muss man doch vom Server bestimmte Objekte oder Datensätze abrufen und kann dann die GUI anweisen, diese darzustellen.
Das möchte ich aber gern automatisieren. Ich möchte normalerweise auch keine Tabellendaten in Gittern oder Daten grundsätzlich in Edits darstellen.
Eine Person soll ein Objekt sein, das alle Informationen kapselt und das als Einheit verwendet werden kann.
Das wird doch mit DataSnap und DataBinding schwierig - oder? Jedenfalls müsste man dann die SubControls händisch mit den untergeordneten Datenobjekten verdrahten.

Werden einige GUI-Controls gezeichnet sorgen sie auch dafür, dass sie die richtigen Daten erhalten. Es ist dafür kein Quelltext im Client notwendig (sondern nur ein Eintrag in "Edit.ssfCtrl.PropName"). Darauf kam es mir an.
Die GUI kann dann (z.B. bei Mengendarstellungen) dynamisch GUI-Controls erzeugen und denen die passende ObjektId zuweisen. Mehr ist nicht notwendig. Auf diese Weise kann der Datenbestand dynamisch abgebildet werden.

Client-Objekte (die Daten-Kopien der BL-Objekte enthalten), die gerade nirgends angezeigt werden (z.B. weil ein Formular geschlossen wurde) können wieder verworfen werden. Wird das Formular geöffnet, werden sie einfach neu abgerufen. Also nur die Daten, die angezeigt werden, sind dem Client bekannt.


Dass es eine Konfliktbehandlung geben muss ist klar. (Ich habe ja bisher lediglich versucht, die Datenübertragung und Datenbindung zu realisieren.)
Auch wenn es nicht ganz so einfach wird: Der ClientManager kann ja grundsätzlich angewiesen werden, mit der Speicherung der Datenänderungen zum Server zu warten bis
- eine Validierung der Änderungen erfolgt ist (dazu müsste allerdings auch beim Server angefragt werden)
und/oder
- der User "Ok" drückt.

Wie gesagt, mir ging es erst mal vorrangig um die Datenübertragung und Datenbindung.