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