C/S mit Objekten - Grundsatzfrage

[stahli]

Ok, vielen Dank für die Mühe!
Ich hoffe, dass ich Dich nicht nicht überstrapaziere - oder dass ich mich jedenfalls mal irgendwann revangieren kann!


Also implementierst Du Deine Objekte als reine Datenspeicher ohne jegliche Funktionalität, die statt dessen komplett im Manager und den dazu gehörigen Klassen untergebracht wird.
Der Einfachheit halber denke ich mir die Visitor und den Writer mal weg.
Dann werden die Objekte an an den Manager übergeben, der die Eigenschaften der Objekte irgendwo speichert. Ok.
Für die Serverseite ist das für mich soweit verständlich.

Aber wie wird im Client auf Änderungen reagiert?
Z.B. soll ein Edit an PersonWithId1.FirstName gebunden werden. Jeder Tastendruck soll den Personennamen an den Server übertragen und dort in der Datenschicht ändern.
Mit DataBinding sehe ich da keine Möglichkeit. Es gibt ja kein Personenobjekt auf dem Client, an das sich das Edit binden kann.
Das Edit müsste dazu eine Id (1), den gewünschten PropertyNamen ("FirstName") und den ClientManager kennen um bei diesem Manager ein entsprechendes Objekt abzufordern, an das es sich dann binden kann.
Ein Standardedit kann das aber ja nicht.
Somit müsste alternativ die GUI (z.B. in Form.Show) die Daten vom Server holen und das Edit händisch an die Daten kleben. Und Glue Code will man ja nicht mehr.

Jetzt wird es noch schwieriger...
Änderungen im Edit werden nun an das Personenobjekt im Client geschickt, welches die Änderung brav in FFirstName vermerkt.
Dadurch geht aber doch keine Meldung an den Server!?

Statt dessen müsste doch (soweit ich das bisher durchschaue) das Edit im OnChange etwa folgendes veranlassen:
ClientManager.SetFirstName(PersonWithId1, EditFirstName.Text); Datasnap schickt den Auftrag dann an den Server, der dann die Änderung vornimmt.
Für jede Klasse und jede Eigenschaft müsste der Manager eine entsprechende Methode bereit halten.

Ist das so?
Ich hoffe nicht!

[Sir Rufo]

Äh, nee, da hast du das Konzept noch nicht verstanden

Das alles ist so für den Client. Auf dem Server könnten die Daten völlig anders abgelegt sein..

Der Manager nimmt die Objekte entgegen und übergibt diese an die Datenschicht.
Was diese Datenschicht damit macht ist der GUI, dem Objekt und sogar dem Manager sowas von egal.
In diesem Beispiel werden die Daten in eine Textdatei gepackt.
Aber wo wäre das Problem, hier etwas zu haben, was die Daten in einen Stream packt und an einen Server sendet. Oder eine email schreibt - gut das ist sinnlos, aber möglich und es würde sich keiner der restlichen Beteiligten daran stören.
Warum auch, der Manager hat den Wunsch der Speicherung durchgereicht und die Datenschicht meldet zurück "ist erledigt"
Jetzt wird natürlich implizit auch erwartet, dass der Wunsch des Ladens ebenso wieder erfüllt wird.
Frage an den Manager, der an die Datenschicht und die muss jetzt zusehen, wie sie da rankommt.

Aber jetzt mal im Ernst, warum sollte jeder Tastendruck an den Server geschickt werden?
Die Oberfläche (z.B. ein Edit) bekommt einen Wert aus einem Objekt geliefert (DataBinding). Dieser kann jetzt verändert werden.
Wenn alle Änderungen erfolgt sind, dann gibt es eine Entscheidung, diese Daten zu speichern.
Also die Daten von der Oberfläche in das Objekt (DataBinding) und jetzt das Objekt an den Manager.
Der Rest ist wie gehabt.

Für eine Validierung der Daten macht es durchaus Sinn, diese vom Manager überprüfen zu lassen.
Die Vorgehensweise ist die gleiche wie beim Speichern, nur dass dem Manager mitgeteilt wird, diese zu prüfen und eben nicht zu speichern.

Wo die Validierung erfolgt (im Client, ein Teil auf dem Client und ein Teil auf dem Server oder ausschließlich auf dem Server) ist dem Objekt und der GUI wieder sowas von egal. Hauptsache es wurde geprüft und man bekommt zurück ob das ok ist oder wo die Fehler sind.

Achja, die Frage wer holt denn jetzt die Daten?

Es wird eine Entscheidung getroffen, einen TStudent mit der ID 5 zu bearbeiten (Doppelklick auf ein Listenelement einer ListView)

Instanz vom Manager laden lassen
EditFormular aufrufen und Instanz übergeben
DataBinding übergibt die Daten an die GUI
Jetzt darf getippt werden bis zum OK (oder Abbruch)
DataBinding übergibt die GUI Daten an das Objekt
EditFormular wird geschlossen
Instanz an den Manager übertragen zum Speichern
fertisch

[stahli]

Dann haben wir uns falsch verstanden (oder zumindest ich Dich).

Ich bin ursprünglich von einem Thin Client ausgegangen, der nur der Darstellung und Eingabe von Daten dient.
Die gesamte Geschäftslogik soll im Server laufen (der evtl. einen ORM nutzt und darüber ggf. auf einen DB-Server zugreift - genau so gut könnten die Objekte des Servers aber auch persistent im Speicher gehalten werden - das würde für die Clients absolut keinen Unterschied machen).
Die Clients müssen sich nur die Daten (Objekte) abholen, die sie gerade anzeigen müssen. Alles andere interessiert sie nicht.
(Der Manager kümmert sich allerdings um eine Zwischenpufferung der Objekten und verwirft sie nach einiger Zeit wieder wenn sie nicht benötigt werden.)

Ich will dann auch nicht ein bestimmtes Objekt (z.B. Person) händisch abrufen und beim Öffnen eines Bearbeitungsformulars mit der GUI verdrahten, sondern die GUI-Controls sollen das selbständig erledigen.
Nach meinen Vorstellungen erhält das Formular einen Controller, dem eine ObjektId zugewiesen werden kann. Daraufhin öffnet er das Formular, auf dem er sich befindet und gibt die Id an alle enthaltenen GUI-Controls des Formulars weiter.
Edit1.MyPropName wurde bereits zur Designtime 'FirstName' zugewiesen und Edit2.MyPropName entsprechend 'LastName'. Die Edits holen jetzt von globalen Manager das Objekt mit der betreffenden Id und binden sich (selbständig) an dessen Propertys "FirstName" bzw. "LastName".
Verschachtelungen sind in diesem Szenario auch möglich. Hat z.B. eine Person ein Unterobjekt "Adress" und dieses die Eigenschaften "City" und "Street" können z.B. zwei Labels die MyPropNames "Adress.City" und "Adress.Street" zugewiesen werden. Über RTTI wird die Zuweisung dann aufgelöst und die beiden Labels an die entsprechenden Eigenschaften des Unterobjektes "Adress" gebunden.

So würde ich mir das wünschen und so nutze ich das bereits in einer Desktopanwendung (jedoch noch nicht als C/S).


Ob nun jeder Tastendruck zum Server gehen soll, darüber kann man natürlich unterschiedlicher Auffassung sein. Ich würde aber dahin tendieren.
Spätestens mit Verlassen eines Edit-Feldes oder nach einer Eingabepause sollte eine Syncronisation erfolgen.
Ändere ich im Objekt den PersonX.FirstName wird ja damit erst mal noch nichts an den Server geschickt und nichts validiert.

Grundsätzlich könnte aber im Setter jeder Eigenschaft (TPerson.set_FirstName, TPerson.set_FirstName usw.) geprüft werden, ob sich das Objekt im Server oder im Client befindet (z.B. ob ein TClientManager existiert) und im letzteren Fall das Objekt zur Übertragung an den Server anmelden (Warteschlange) oder es auch sofort vom Server validieren lassen.

Im Client will ich letztlich nur die Controls platzieren und die Eigenschaftsnamen zuweisen. Per Code muss dann nur die GUI-Logik geschrieben werden.
Die GUI muss nichts von den Objekten wissen.

Ein Framework beschafft im Hintergrund die Datenobjekte und bindet sie per RTTI an die GUI-Controls (sofern ein entsprechendes Objekt gefunden wurde und die in "MyPropName" angegebene Eigenschaft existiert - sonst wird das Control gecleart).


Die BusinessLogic soll m.E. komplett im Server laufen. Der Client braucht demzufolge auch gar keine geschäftsfähigen Objekte sondern letztlich einfach nur die Daten.
Die Frage ist für mich allerdings, wie man die Businesskommunikation zwischen Client und Server abwickelt, die über reine Datenänderungen hinaus gehen.
Dieses Problem löst ja offenbar DataSnap, jedoch ist mir das alles zu komlex, als dass ich da einen Einstieg finde. Ein paar frühe Demovideos sahen ganz interessant aus. Das aktuelle erschlägt mich aber ziemlich.


Sir, bei Deiner Zusammenfassung kann ich auch nicht komplett folgen, Sir (jedenfalls nicht in der Reihenfolge):
- Instanz vom Manager laden lassen
ok
- EditFormular aufrufen und Instanz übergeben
ok
- DataBinding übergibt die Daten an die GUI
Hier musst Du die Datenbindung von Hand vornehmen, oder?
Entweder kannst Du klassisch Edit1.Text:=Person.FirstName vornehmen oder Du musst in ähnlicher Weise ein LiveBinding (im Quelltext) vornehmen.
- Jetzt darf getippt werden bis zum OK (oder Abbruch)
ok
- DataBinding übergibt die GUI Daten an das Objekt
Das ist missverständlich. Die Daten WURDEN bereits per LiveBinding in das Objekt geschrieben oder im anderen Fall musst Du wieder Person.FirstName:=Edit1.Text zuweisen.
- EditFormular wird geschlossen
Und hier muss entschieden werden, ob die neuen Daten des Objektes gespeichert (also an den Server geschickt) werden sollen (ggf. mit vorheriger Validierung) oder nicht.


Dein Szenario würde ich letztlich nicht einmal als wirkliche C/S-Anwendung, sondern eher als Datenbankanwendung bezeichnen wollen (Ich biete Dir bereits hier eine Friedenspfeife an! ).
Die Clients sind eigenständige Programme, die ihre Daten an einer zentralen Stelle speichern und gemeinsam darauf zugreifen.
Das macht jede Datenbankanwendung so, nur dass Du die Daten in Objekten weiter verarbeitest.

Oder lehne ich mich da zu weit aus dem Fenster?
Oder ist es einfach schon wieder zu spät für mich? Nachti!

[Phoenix]

Zitat von stahli:

Dann haben wir uns falsch verstanden (oder zumindest ich Dich).

Ich bin ursprünglich von einem Thin Client ausgegangen, der nur der Darstellung und Eingabe von Daten dient.
Die gesamte Geschäftslogik soll im Server laufen (der evtl. einen ORM nutzt und darüber ggf. auf einen DB-Server zugreift - genau so gut könnten die Objekte aber auch persistent im Speicher gehalten werden - das würde für die Clients absolut keinen Unterschied machen).
Die Clients müssen sich nur die Daten (Objekte) abholen, die sie gerade anzeigen müssen. Alles andere interessiert sie nicht.
(Der Manager kümmert sich allerdings um eine Zwischenpufferung der Objekten und verwirft sie nach einiger Zeit wieder wenn sie nicht benötigt werden.)

Das willst Du nicht wirklich. Natürlich interessiert den Client die Geschäftslogik. Und zwar sowas von.

Insbesondere zum Beispiel die Validierung. Wenn ich auch nur anfange falsche Usereingaben zu machen, dann soll mich die GUI *sofort* darüber informieren - und nicht erst, wenn ich nach der Mittagspause zurück komme und auf 'speichern' drücke - und dann das ganze erst zum Server geht und dort erst validiert wird.

Die Idee mit 'die Anwendung geht sofort zum Server' kannst Du unmittelbar verwerfen. Das Skaliert nicht. Der Server müsste für jeden Client ein eigenes Datenuniversum vorhalten (was ist, wenn ein User nahezu alle Daten verändert, aber nie auf Speichern klickt?). Was ist, wenn die Netzwerkverbindung ausfällt? Das ganze ist nur für extrem beschränkte Anwendungsfälle möglich, und jede kleine Anforderung die es erfordert, aus dieser 'Immer da, unendlich bandbreite, kurze Roundtrips, genug Serverkapazität'-Komfortzone auszubrechen ist mit Deiner Architektur nicht abbildbar und erfordert unmengen an Aufwand.

Und natürlich kannst Du die Validierung auch nicht komplett auf den Client verschieben. Der Server kann sich niemals sicher sein, dass ein 'korrekter' Client mit ihm spricht und ihm bereits validierte Daten liefert. Er muss die Validierung zwangsläufig nochmal durchführen. Es hätte ja jemand die Kommunikation abhören können und der schickt nun gefälschte Anfragen.


Rockford Lhotka hat in seinem Buch 'Expert C# 2008 Business Objects' (http://www.amazon.com/Expert-C-2008-.../dp/1430210192) ziemlich viele geniale Konzepte über Verteilte Anwendungen beschrieben. Seine Implementierung hat er - wie der Name schon sagt - für .NET umgesetzt, aber in dem Buch geht es mehr um die Konzepte dahinter.

Die Idee ist es, eine verteilte Anwendung so aufzuteilen, dass es egal ist, wo welche Schicht läuft.
Das heisst in dem konkreten Fall einer klassischen 3-tier Anwendung (DB, Appserver & Client) läuft die absolut identische Businesslogik *sowohl* auf dem Server als auch auf dem Client. Nur so kann eine gescheite, sofortige Reaktion auf die Usereingabe erfolgen und der Server sicher sein, dass valide Daten vorliegen. Du hast aber durch diese Architektur auch sofort die Möglichkeit, dass der Appserver weggelassen wird und Du, nur durch umkonfigurieren und ausrollen einer zusätzlichen dll (die die Datenzugriffsschicht enthält) aus der 3- eine 2-Schicht Anwendung zu machen (das klassische Client/Server Modell: Client-Anwendung gegen Datenbank-Server).

Aber im Prinzip versuchst Du hier

[jobo]

@Phoenix
Das sind interessante Ideen, aber die Umsetzung halte ich doch für recht aufwändig. Was soll man hier unter Business Logik verstehen?

Ein Server ist ein Server ist ein Server. Dient z.B. dazu, referenzielle Integrität sicherzustellen. Überhaupt ist er dazu da, sämtliche Fehleingaben abzuwehren. Ein dummer Client, ohne jegliche Eingabekontrolle, sollte es nicht schaffen, Fehleingaben durchzudrücken.

Wie soll sich bspw. ein intelligenter Client als Server verhalten, ohne selbst ein komplettes Datenbank-Replikat zu halten, was ja die Validierungsgrundlage ist?
Business Logik lebt doch im gesamten Datenkontext, idR. ein Mehrbenutzersystem, das nicht selten auch automatisiert Daten aus 3. System verarbeitet, wie und auch warum sollte auf einer solchen Basis eine Business Operation im Client ablaufen? In vielen Fällen mag das Sinn machen, aber als pauschales Konzept scheint mir das nicht sehr sinnvoll.

[Phoenix]

Zitat von jobo:

Wie soll sich bspw. ein intelligenter Client als Server verhalten, ohne selbst ein komplettes Datenbank-Replikat zu halten, was ja die Validierungsgrundlage ist?
Business Logik lebt doch im gesamten Datenkontext, idR. ein Mehrbenutzersystem, das nicht selten auch automatisiert Daten aus 3. System verarbeitet, wie und auch warum sollte auf einer solchen Basis eine Business Operation im Client ablaufen? In vielen Fällen mag das Sinn machen, aber als pauschales Konzept scheint mir das nicht sehr sinnvoll.

Niemand - auch kein intelligenter Client - braucht für einen atomaren Vorgang das gesamte Datenuniversum. Die Referenzielle Integrität betrifft in aller Regel nur unmittelbar zusammenhängende Datensätze. Die einzige Ausnahme wäre hier eine PK-Verletzung, weil ein Client etwas neu einfügt was schon da ist - was dann aber eher auf ein Usability-Problem hinweist, denn eine gute Software würde dem User vorher den schon existierenden Datensatz präsentieren und ihn nicht erneut eingeben lassen.

Heutzutage geht die Entwicklung sehr Stark in Richtung 'disconnected processing'. Ein gewisses Subset des Datenuniversums (meist Stammdaten + relevante Bewegungsdaten) exisitiert auf mehreren Devices, die ohne permanente Verbindung zum 'Backend' autark arbeiten - und sich dann in mehr oder weniger regelmäßigen Abständen synchronisieren. Ggf. laufen auch immer nur Teilbereiche einer Anwendung auf diese Art (z.B. Live-Auswertungen für das Management auf Tablets).

Das Problem ist hierbei, das solche Anforderungen nie von vorneherein auf der Spezifikation stehen, sondern erst später dazu kommen. Eine vernünftige Architektur sollte in der Lage sein, solche Szenarien relativ einfach zu ermöglichen - eine schlechte Architektur erschwert bzw. verhindert solche späteren Anpassungen.

[Sir Rufo]

@Phoenix

Das gesamte Konstrukt ist Client/Server und nicht weil ich 2 Programme an 2 verschiedenen Orten habe.

Die GUI (Client) spricht mit dem Objekt und dem Manager (Server)
Der Manager (Client) spricht mit dem DatenLayer (Server)
Der DatenLayer (Client) spricht mit dem Betriebssystem um die Daten zu speichern (Server)

Der Clou an der Sache ist, dass der Client nicht wissen muss, wie die Verarbeitung im Server umgesetzt ist.
Jeder Server kann auch ein Client eines anderen Servers sein und ist dann eigentlich nur eine Leitstelle.
Dem Client davor ist das aber herzlich egal.

Und wenn alles in eine Anwendung gegossen wird (weil rein Single-User-Betrieb) dann ist das bei der Umsetzung immer noch C/S