C/S mit Objekten - Grundsatzfrage

[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.

[mjustin]

Zitat von stahli:

Kannst Du mal noch andeuten, wie Du dann

Delphi-Quellcode:

  TSchoolManager.Save( ASchoolSubject : TSchoolSubject );
  TSchoolManager.SwipNames( APersonSubject : TPersonSubject; AAge : Integer );

implementierst?

Bei einer serviceorientierten Architektur wäre die zweite Methode etwas modifiziert einfacher und schlanker zu lösen:

  procedure TSchoolManager.SwipNames( ASchoolSubjectID : TSchoolSubjectID; AAge : Integer );

anstatt dem Service ein "komplettes" Objekt zu übergeben, was unter Umständen wiederum Unterobjekte / Listen von Objekten enthält, würde nur seine ID benutzt (die ein einfaches Integer Feld, eine GUID oder auch eine aus mehreren Elementen zusammengesetzte Struktur sein kann).

Diese wird serialisiert an den Server gesendet, der dann die gewünschte Operation mit dem Objekt ausführt.

Auftretende Fehler würde ich per (serialisierter) Exception an den Client zurücksenden.

Bei einer serviceorientierten Architektur wäre der Service, der den TSchoolManager implementiert, komplett zustandslos, das bedeutet das die Anwendungslogik im Client liegt.

[stahli]

Dass über das Protokoll eine ObjektId übertragen wird ist schon klar.

Ich meinte mit meiner Frage, ob Du dann die Ausführung im Objekt "TPerson.SwipNames(...)" durchführen würdest (also Objekte auch Businessfunktionalitäten ausführen können) oder ob Du das grundsätzlich vermeiden (und nur vom Manager aus, also von außen, den Tausch der Werte des Objektes vornehmen) würdest.
Inzwischen hat sich die Frage für mich aber erübrigt, da in meinem aktuellen Test im Client kein TPerson-Objekt erzeugt wird sondern lediglich TClientDataObjekte, die als Datenspeicher dienen. Realisiert wird das über eine StringList und dessen Names und Values.

Delphi-Quellcode:

  TClientDataObject = class(TComponent)
  private
    FId: TssfId;
    FTS: TDateTime;
    FSL: TStringList;
    FLTS: TDateTime;
  public
    constructor Create(Owner: TComponent); override;
    destructor Destroy; override;
  published
    property Id: TssfId read FId write FId;
    property TS: TDateTime read FTS write FTS;
    property SL: TStringList read FSL write FSL;
    property LTS: TDateTime read FLTS;
  end;

Der Client und die ClientDataObjekte wissen somit nichts von den eigentlichen Geschäftsobjekten (abgesehen davon, dass man noch so eine Art ClassName zuweisen kann, den der Client bei Bedarf interpretieren kann).
Es ist somit möglich, die Businessobjekte mit einer vollständigen Funktionalität auszustatten, ohne dass dies auf dem Client störend sein könnte.

Auf dem Client müsste lediglich die GUI-Logik laufen, die ggf. beim Server die benötigten Informationen abholt.

[mjustin]

Zitat von stahli:

Inzwischen hat sich die Frage für mich aber erübrigt, da in meinem aktuellen Test im Client kein TPerson-Objekt erzeugt wird sondern lediglich TClientDataObjekte, die als Datenspeicher dienen.

Ja, das würde ich ähnlich lösen - Businessobjekte mit deren Logik existieren nur auf dem Server, und für den Client stellt man Data Transfer Objekte bereit, die einfacher zu übertragen sind, und keinerlei Geschäftslogik enthalten. Wie diese DTOs verpackt werden (als Stringliste oder mit klassischen Properties) spielt erst mal keine Rolle.

Komplex wird es dann wenn ein Businessobjekt auch Objekt-Properties haben kann, wie Person.Adresse - wie soll das Adress-Objekt auf den Client abgebildet und angesprochen werden?

[stahli]

Mal in´s Unreine:

Es gibt ein Datenobjekt 1, das Personendaten enthält:

Code:

Objekt1
#Id=1
#TS=Uhrzeit der letzten Änderung
#ClassName=Person (Für Interpretationen auf dem Client)
FirstName=André
LastName=Stahl
Adress=2 (Id)

und

Code:

Objekt2
#Id=2
#TS=Uhrzeit der letzten Änderung
#ClassName=Adress (Für Interpretationen auf dem Client)
Country=Halle
Street=Pekinger Str

(wobei die ID´s GUID´s o.ä. sind)

Wenn ein Edit Id=1 und PropName='FirstName' zugewiesen bekommt, holt es sich vom Manager Objekt1 und nutzt (wenn vorhanden) dessen Eigenschaft FirstName.
Ein anderes Edit soll Id=2 und PropName='Street' verwenden. Das macht dann keinen Unterschied und es ist egal, welche Businessobjekte da letztlich representiert werden.

Ein drittes Edit kann aber auch einfach PropName='Adress.Country' zugewiesen bekommen. Wenn es z.B. in einem Bearbeitungsformular für eine Person liegt würde das Formular die PersonenId erhalten und diese an alle untergeordneten Controls weiter geben.
Das Country-Edit würde zunächst nun das Objekt1 beim Manager abrufen, wobei der auf Grund des Punktes in PropertyName noch prüft ob Objekt1.Adress eine gültige Id enthält und dann statt dem Objekt1 eben das Objekt2 zurück gibt und dessen Eigenschaft "Country" weiter verwendet wird.

Intern gibt es daher tatsächlich die Eigenschaften:
- Id
- PropName
- usedId
- usedPropName

Der Manager kümmert sich also sebständig um die Auflösung von Unterobjekten.

[Jumpy]

Nur mal so eine Grundfrage, wie das bei der Tuniersoftware gedacht ist. Wo liegen dann Client und Server? Auf verschiedenen Computern? Was ist, wenn dann mal keine Verbindung besteht? Kann der Client dann allein weiter machen oder muss das Tunier ausfallen?

Frage nur so aus Neugier, da ich am WE mein Patenkind auf einem Tischtennistunier besucht habe und da war auch irgendeine Software am laufen. Da wurden immer wieder Paarungen ausgedruckt und an auf die vorhandenen "Platten" verteilt. Die Eingetragenen Ergebnisse mussten dann ruckzuck an den Mann mit dem Notebook gegeben werden, der das dann eingetragen hat, woraus sich dann wieder neue Paarungen ergaben, usw.

Hinterher müssen diese Daten wohl auch auf einer speziellen Webseite des Verbandes hochgeladen werden für sowas wie die Gesamt-Rang-Liste.

[taveuni]

Guter Einwurf!
Mein Sohn spielt in einem Fussballclub welcher dieses Jahr das erste Mal das Dorfturnier durchgeführt hat.
Der Club hat dann auch so ne Software gekauft (nicht von Stahli). Das war eine einzige Katastrophe.
Denn es sollte doch zumindest möglich sein auf den verschiedenen Plätzen die Ergebnisse einzutragen (clients).

Und dann von mir aus via Lan oder Datei oder weiss der Geier irgendwie mit dem Server zu synchronisieren.
Aber auch hier wurden dann Zettel ausgedruckt zur Zentrale gerannt, dort wieder abgeschrieben...

Kann ja wohl nicht wahr sein?

[stahli]

@Jumpy

Meine aktuelle Turniersoftware [SchleichWerbung], die übrigens auch und gerade für Tischtennis sehr geeignet ist [/SchleichWerbung] hat zwar bereits eine Trennung von GUI und BL, ermöglicht jedoch nicht den Zugriff mehrer Clients auf die Daten. GUI und Objekte müssen derzeit in der selben Anwendung existieren.
Innerhalb der Anwendung funktionieren die Objekte allerdings schon autark. Die Objekte benötigen also keinen Zugang zur GUI und die GUI auch keinen (direkten) Zugang zu den Objekten. Die Vermittlung übernimmt eine Zwischenschicht.
Die Programmlogik wird also niemals irgendwo nachsehen, ob im FormularXy.CheckBoxZ.Checked gesetzt ist. Die Programmlogik weiß nicht einmal welche Formulare das gibt und ob überhaupt eine GUI existiert.

An dieser Grundlage soll sich auch nichts ändern. Jedoch soll es möglich sein, mehrere Clients (auch auf verschiedenen PC´s) mit den Daten zu bedienen.
Im Server soll der gesamte Turnierzustand verwaltet werden. Die Clients können dann auf den Server zugreifen, die Daten abrufen und Änderungen initiieren.
Der Server kann dann (das wird der Regelfall sein) mit einem (Haupt-)Client auf einem PC laufen, so dass ein Netzwerkausfall unschädlich wäre, während weitere Clients über ein Netzwerk zugreifen könnten.
Es wäre aber auch ein emebeded Server möglich, so dass Client und Server in einer Anwendung laufen und somit der Server nur genutzt wird um eine eindeutige Trennung zwischen GUI und BL zu gewährleisten und ggf. später doch externe Clients anzubinden.

Also für den Anwender müsste sich grundsätzlich nichts ändern, außer dass man Alternativen für weitere Clients erhält.


@taveuni

Mein Programm unterstützt auch Mannschaftssportarten wie Fußball. Aber ich bin erhrlich gesagt nicht so recht überzeugt, dass man dafür eine Software benötigt.
Ein Spiel läuft 2 Stunden. Dann kann man das Ergebnis per Handy durchgeben und erhält von mir aus per Mail einen aktuellen Zwischenstand.
Alternativ wäre eine Website denkbar, in der nach Anmeldung die Punkte eingetragen werden könnten.
Vielleicht habe ich auch falsche Vorstellungen von dem Turnier, aber irgendwie erschließt sich mir der Nutzen einer netzwerkbasierten Software nicht recht dafür.
Wenn mein Projekt sich wie erhofft weiter entwickelt, dann würde es eine solches Turnier aber unterstützen (jedenfalls wenn ein Netzwerk vorhanden wäre - wie das über Internet ginge, kann ich derzeit nicht beurteilen).

Im Gegensatz zu Mannschaftssportarten ist der Verwaltungsaufwand bei Tischtennis, Badminton usw. sehr viel höher, da die Platten oder Felder sehr viel stärker frequentiert werden und da die Teilnehmer in einem Turnier oft in unterschiedlicher Weise und mit unterschiedlichen Partnern spielen müssen. Es herrscht also ein ziemliches Durcheinander, das ohne Software kaum sinnvoll zu beherrschen ist. Wird ein Feld frei, muss die Turnierleitung entscheiden, wen sie als nächstes aufruft. Es müssen alle noch zu absolvierenden Spiele gepüft werden, ob alle beteiligtenj Spieler gerade verfügbar sind und wann sie zuletzt gespielt haben. Dann spielt aber auch der bisherige Turnierverlauf und die Zeitplanung für die Entscheidung noch eine Rolle.

Beim Fußball ist das alles natürlich deutlich einfacher. Aber da spielt man ja auch sowiso nur mit dem Fuß.

[taveuni]

Also bei unserem Dorfturnier (und wir sind eine kleine Gemeinde) welche einmal im Jahr stattfindet war es dieses Jahr so:
- 135 Mannschaften
- Mannschaften in 5-er Gruppen (Durchschnitt) round robin.
- 3 Fussballplätze
- Spieldauer Junioren 2x6 Minuten, Erwachsene 2x10 Minuten.
- Achtelfinals, Viertelfinals, Halbfinals, Final.
- Pause zwischen den Spielen 30 Sekunden.
Das alles in 2 Tagen!

Also auch hier ist viel Dynamik in der Luft. Wenn die Gruppenspiele dem Ende entgegen gehen wollen/müssen die Mannschaften
ziemlich kurzfristig wissen wo und wann das nächste Spiel gegen welchen Gegner usw.

Viele "Veranstalter" (Vereine) versuchen das mit Excel und Makros irgendwie hinzukriegen.

Ich träume von einer (verteilten) Software welche das verwaltet. Spielausfälle usw. automatisch verarbeitet.
Zwischenranglisten und Spielpläne dynamisch (Webserver) zur Verfügung stellt usw.

Also los ans Werk! Sonst setz ich mich selbst mal dran

[stahli]

Aha, also fast Badminton mit rundem Ball und Fuß...

Vorschlag:
Ihr könnt Euch ja mal mein (aktuelles) Programm ansehen, ob das grundsätzlich nützlich wäre.
Mannschaftssportarten kann es ja auch verwalten.
Wenn Du mir per pn Deine Mailadresse schreibst, schicke ich Dir auch gern eine Testlizenz, damit Du alle Möglichkeiten nutzen und Turniere speichern kannst.

Eine verteilte Anwendung habe ich im Moment noch nicht, will das ja aber mal in Angriff nehmen (incl. einer Überarbeitung der gesamten Objektverwaltung).