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