C/S mit Objekten - Grundsatzfrage

[stahli]

Ich habe mal ansatzweise überlegt, wie so eine Anwendung strukturiert wird.
Also ich würde mir das wie in der Skizze vorstellen:

Im Server gibt es eine Factory, die auf Anfrage Businessobjekte erzeugt bzw. heraus gibt.
Z.B. die Schüler, Lehrer, Klassen und Zimmer einer Schule.
Bei der Anfrage kann die ID des gewünschten Objektes übergeben werden. Sonst kann auch ein neues Objekt erzeugt werden.
Die Factory bleigt Eigentümer der Objekte und gibt die nach einiger Zeit und vollem Puffer wieder frei.
Intern werden die Daten über einen ORM aus einer Datenbank geholt.

Die gesamte Geschäftslogik läuft in den Objekten, die die Factory erzeugt. Greift ein Objekt auf ein anderes zu, holt es sich entsprechend auch über die (eigene) Factory.

In den Clients gibt es auch eine Factory, die eine bestimmte Menge an Objekten puffern kann und die ggf. wieder verwirft.
Allerdings holt diese die Daten über ein Protokoll vom Server.

Die GUI-Controls holen sich die Daten aus den Eigenschaften der Objekte, die die Factory bereit stellt.
An der Stelle fällt mir ein, dass das neue LiveBinding dafür nicht taugen wird, da die GUI-Controls jeweils eine ObjektId (z.B. PersonId) und die Factory kennen, bei Bedarf von der Factory ein entsprechendes Objekt abrufen und sich dann selbst an die gewünschte Objekteigenschaft (z.B. Person.FirstName) binden müssen. Insofern wird hier das Konzept meiner bisherigen odControls in ähnlicher Form sinnvoller sein als das (durchaus interessante) LiveBinding.

Die Clients müssten beauftragt werden, sich neu zu zeichnen, wenn im Server Änderungen erfolgen.
Objekte haben einen Zeitstempel, in dem die letzte Änderung gespeichert wird (Uhrzeit auf dem Server). Wenn das lientobjekt den gleichen Zeitstempel hat muss das Objekt nicht neu zum Client übertragen werden.
Ebenso müssen die Clients Datenänderungen natürlich an den Server schicken.


Bis hierher ist mir alles so ziemlich klar und klingt machbar.
Hoffe, dass Ihr mir das nicht alles um die Ohren haut...


Z.B. eine Namensänderung einer Person lässt sich so recht leicht syncronisieren. Wie geht man aber mit komplexen Methodenaufrufen um, die die Geschäftslogik betreffen?
Z.B. könnte es eine Methode geben TStudent.MoveToClass(Class: TClass) geben. Diese Aktion kann ja nicht im Client durchgeführt werden.
Wie gibt man diese denn an den Server weiter? Als Zeichenkette, die der Server dann wieder (per RTTI?) als Objektmethode ausführt? Dann müsste aber u.U. auch wieder ein Result an den Client geschickt werden (für eine sinnvolle Reaktion der GUI und Focusänderung)!?
Dann müssten die Objekte jeweils wissen, ob sie sich im Server oder Client befinden. Im Client könnten die Methoden "normal" arbeiten und im Client müssten sie eine Anweisung an den Server schicken.

Gibt es irgendwo Informationen, wie solche Anwendungen arbeiten?

[mjustin]

Zitat von stahli:

Gibt es irgendwo Informationen, wie solche Anwendungen arbeiten?

Patterns of Enterprise Application Architecture (Martin Fowler, verlegt bei Addison Wesley) hat dazu einige Kochrezepte.

Ich bin ein großer Fan des "Service Layers" - der Client spricht mit einem zustandslosen Service Layer, das ist eine Art Interface bei dem der Client die komplexeren Aktionen wie MoveToClass als Remote Procedure Call ausführt. Auch "Remote Facade" und "Data Transfer Object" sind wichtige Patterns.

Ich setze diese Patterns in Java Enterprise Edition Anwendungen an. Geht aber analog auch mit Delphi. Zwischen den Schichten wie Webanwendung (serverseitig) und Enterprise JavaBean (auch im Server) werden dann Data Transfer Objekte über eine "Facade" ausgetauscht.

[stahli]

Michael, danke für den Tipp. Das Buch habe ich heute (in deutsch) bestellt und darf vor dem Kauf auch nochmal rein schauen.


Aber mal noch eine grundsätzliche Frage zur Realisierung über DataSnap.

Ich würde in meinem Client ein Panel verwenden, das (wie im Bild) einen Schüler darstellt. Durch Doppelkick soll eine Funktion Student.SwipNames(Age:Integer):Boolean aufgerufen werden, die den Vornamen und Nachnamen vertauscht und ein Alter zuweist (auch wenn das natürlich recht sinnfrei ist).

Implementiert wäre das etwa so:

Delphi-Quellcode:

function TStudent.SwipNames(Age_:Integer): Boolean;
var
  S: String;
begin
  S := FirstName;
  FirstName := LastName;
  LastName := S;
  Result := (Age <> Age_);
  Age := Age_;
end;

In einer Desktopanwendung würde PanelStudent, wenn es das Student-Objekt kennt ja einfach die Methode aufrufen und gut ist.

Über DataSnap würde ja eine Persistentklasse registriert (hier mal TSchool), die im Client und Server bekannt ist.
Jetzt kann der Client Methoden von TSchool ausführen, die DataSnap zum Server weiter leitet.

Von TStudent direkt können aber keine Methoden ausgeführt werden - oder?

Also müsste man eine neue Funktion

TSchool.Student_SwipNames(Student: TStudent; Age_:Integer): Boolean
bzw.
TSchool.Student_SwipNames(StudentId: Integer; Age_:Integer): Boolean

einführen, der das Student-Objekt oder dessen Id übergeben wird und die dann die eigentliche Funktion ausführt. Richtig?


Das PanelStudent dürfte dann beim Doppelklick nicht die StudentObjekt-Methode ausführen, sondern die School-Methode auf dem Server starten.
Aber es dürfte keine Methode eines im Client instanziierten Student-Objektes ausgeführt werden. Das StudentObjekt müsste sich also unterschiedlich verhalten, je nachdem ob es im Client oder auf dem Server instanziiert wurde.
Oder gibt man an den Client nur reine Datenobjekte ohne jede Geschäftslogik?
Ich komme da zu keinem Schluss...

Funktioniert das so? Bzw. wo liege ich daneben? Wie kommt das Result zurück zum Client?
Wie sieht ein Setter (z.B. set_FirstName) eines TStudent-Objektes im Client aus? Dort klassisch Value an FFirstName zuzuweisen macht ja keinen Sinn...

Gibt es dazu Infos?

(Sonst finde ich Demos und Erklärungen zu DataSets, die für meinen Anwendungsfall ja nicht passen.)

[Sir Rufo]

Also auch bei einer Desktop-Anwendung würde ich dem Model keine weiterführende Funktionalität zuweisen, sondern dieses eben auch an eine Methode einer Verwaltungsklasse übergeben.

Diese Verwaltungsklasse ist bei C/S aber nur eine Durchreiche an den Server und die Bearbeitung findet dort statt.

Also statt

Delphi-Quellcode:

TStudent.SaveTo(WhereEver);
TStudent.SwipNames(AAge : integer)

nehme ich lieber

Delphi-Quellcode:

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

Delphi-Quellcode:

TSchoolSubject = class
...
end;
TPersonSubject = class(TSchoolSubject)
...
end;
TStudent = class( TPersonSubject )
...
end;

Warum?

Der Manager weiß, ob und wenn ja wohin und wie er speichern soll.

[stahli]

Ok, in dem Zusammenhang klingt das plausibel. Aber die Möglichkeiten der OOP werden dadurch ja eigentlich nicht ausgeschöpft bzw. zu Gunsten anderer Aspekte zurückgefahren.

Kannst Du mal noch andeuten, wie Du dann

Delphi-Quellcode:

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

implementierst?

Würdest Du dann die entsprechende Ausführung letztlich doch in den übergebenen Objekten ASchoolSubject.Save (sofern kein Serialisierer eingesetzt würde) und APersonSubject.SwipNames(AAge) vornehmen oder die Objekte lediglich wie Records ohne Funktionalität behandeln?
Wenn die Funktionalität in den Objekten steckt, müsste aber sicher gestellt sein, dass diese auf den Clients (dort können die Objekte ja auch instantiiert werden) nicht ausgeführt wird (z.B. durch eine Reaktion auf einen bestimmten Wert in einem Setter).

Vielleicht wäre es ja daher doch nicht so verkehrt, die Daten zwischen Server und Client als DataSets zu übertragen und nur auf dem Server mit Business-OOP zu arbeiten?

Oder man erstellt reine Datenklassen, die man im Client verwendet und für den Server um die Businesslogic erweitert. Aber dann passt das mit der Übertragung nicht zusammen. Und selbst wenn man in einem Setter ggf. den Value korrigieren würde, wäre das ja schon eine Art Businesslogic!?

Ach Mann - ich koche mir lieber erst mal noch einen Kakao...

[Sir Rufo]

Im Anhang mal ein Mini-Beispiel (nur Source) mit der Speicherung in einem FlatFile.

Für alle anderen Speicherorte/-ziele (DB,XML,etc.) einfach einen entsprechende Handler schreiben.
Das Model und der Manager bleiben davon unberührt ... und das ist auch gut so.

Besondere Beachtung bitte der Klasse TVisitor schenken, die habe ich dem Uwe gRaabet

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