Klasse aus Datenbank füllen, danach die Klasse verarbeiten

[Rolf B]

Hallo dedlfix,

um das für das Thema ORM mal zu adressieren: Aus meiner Sicht kann es sinnvoll sein, eine Basisklasse "DatamodelObject" oder so zu vergeben, die das Interface für ORM bereitstellt und die mittels Reflection oder abstrakten Methoden die nötigen Informationen für das Mapping bereitstellt, aber die Kopplung an eine konkrete Repositoryimplementierung würde ich per DI durchführen.

Als Alternative zum DatamodelObject gibt es auch das Decorator-Pattern, d.h man erzeugt (dynamisch) eine Klasse, die alle Methoden/Properties des Datenmodell-Objekts kopiert, plus die nötigen ORM Methoden mitbringt. Ein Objekt dieser Klasse wird dem Datenmodell-Objekt vorgeschaltet und delegiert alle kopierten Methoden und Properties dorthin. Bei der Gelegenheit kann der Aufruf eines Setters auch automatisch ein "Changed" Bit setzen. Das setzt natürlich eine Sprache voraus, in der man Property-Getter/-Setter bauen kann. Alternativ kann man auch eine Klasse erzeugen, die von der Datenmodell-Klasse erbt; aber ohne programmierbare Getter/Setter ist das auch langweilig.

Ich habe sowas vor 15 Jahren mal in C# gebaut, da haben wir die DatamodelObject Basisklasse verwendet und in jeder konkreten Klasse des Datenmodells ein Setter-Muster benutzt, um Property-Changes zu signalisieren. War einiges an Boilerplate, aber dynamische Generierung von Klassen war mir damals noch fremd. Vor 25 Jahren hatte mein Unternehmen sowas als Standardsoftware auf der damals verwendeten Smalltalk-Plattform, da designte man die Fachklassen und ließ die Implementierung mit allem Boilerplate generieren. Dependency Injektion des ORM System war da aber nicht vorgesehen und Unittests unmöglich...

Insofern: Ich habe schon einiges an Schmerzen mit ORM erlebt…

Rolf