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!