Design-Frage: Platzierung der Save-Methode

[Lowpass]

Hallo zusammen
In diesem Thread würde ich gerne ein paar Meinungen zu einer Design-Frage lesen, die ich im folgenden etwas genauer schildere:
Es geht um das Speichern von Objekten in eine Datenbank. Diese Datenbank ist sehr dynamisch (worauf ich nicht genauer eingehen will), was die Verwendung eines selber programmierten Moduls zwingend notwendig macht. Persistierungs-Frameworks sollen also in dieser Frage nicht weiter berücksichtigt werden, denn das DB-Zugriffs-Framework ist fest gesetzt und wird von einem anderen Entwicklungs-Team zur Verfügung gestellt.

Um zu speichern, greife ich also auf dieses Daten-Integrations-Modul zu, welches mir vorschreibt, wie Objekte zu speichern sind.
Momentan sieht es so aus, dass ich in meinem eigenen Modul eine Klasse "DbManager" habe, in welcher sich der gesamte Zugriff auf die Daten-Integration befindet und welche als Singleton erzeugt wird (per Dependency Injection mit Spring). Wenn nun also ein Objekt vom Typ "X" gespeichert werden soll, dann rufe ich dbManager.saveX(InstanzVomTypX) auf.

Es war für mich das nahe liegendste, das so zu lösen - aber wenn ich mir weiter Gedanken dazu mache, dann frage ich mich halt, ob die Klasse X nicht ihre eigene Save-Methode haben sollte - also dass dann der Aufruf erfolgt durch instanzVomTypX.save();
- dann müsste halt jede Instanz von X eine Referenz auf meinen dbManager haben. Wäre das nicht viel "objektorientierter"? Aber ist es nicht irgendwo undurchsichtig, dass dann alle Objekte eine eigene Referenz auf den DbManager haben?

Die Methoden im DbManager statisch zu machen schliesse ich aus, da ihm per Spring die Referenzen zu den DatenIntegrations-Objekten übergeben werden, die eben auch nicht statisch sind (das Klassenmodell ist ein Objekt vo Typ Klassenmodell, das Objektmodell ist eine Instanz vom Typ Objektmodell etc) - oder ist das kein Grund?

Ich bin in solchen Dingen sehr unerfahren und würde mich sehr über ein paar Stellungsnahmen mit kurzen Begründungen freuen.

 

[FArt]

Typischer Fall für z.B. DAOs, also das Data Access Pattern...

Den Manager statisch zu machen ist auch nicht klug, denn mit Spring und DI hast du im Prinzip das selbe Resultat, nur praktischer.

 

[Lowpass]

Danke für den Beitrag. Das konsequente Umsetzen von DAOs ist aber leider aufgrund der DatenIntegration nicht möglich.
Grundsätzlich habe ich auf meiner Seite (mit JAXB erzeugte) DTOs und muss diese in Objekte umwandeln, welche die DatenIntegration mir vorgibt. Aufgrund des dynamischen Modells sind es immer Objekte vom gleichen Typ, die bestimmte Felder haben (die üblichen Verdächtigen wie id, name, ladt modified etc.) und eine Liste von Attribut-Objekten, welche die für das konkrete DTO speziellen Attribute repräsentieren.
Das fertig gestellte Objekt besitzt aber keine Save-Methode, sondern muss von mir beim Aufruf einer create bzw save-Methode der DatenIntegration übergeben werden.

Wenn ich den DAO-Ansatz richtig verstehe, dann müsste das standardisierte Objekt der DatenIntegration, in das ich meine DTOs umwandle, eine save-Methode haben - hat es aber nicht und darauf habe ich leider keinen Einfluss.
Wenn ich also auf meiner Seite DAOs haben wollte, müsste ich eine neue Zwischenstufe einführen...

ich hoffe das ist einigermassen veständlich. Es ist mir klar, dass wir hier einen etwas komplizierten Ansatz haben und ich habe mich schon genug darüber geärgert.

 

[maki]

Wenn ich den DAO-Ansatz richtig verstehe, dann müsste das standardisierte Objekt der DatenIntegration, in das ich meine DTOs umwandle, eine save-Methode haben

Du verwechselst DAO mit ActiveRecord, DAO ist schon richtig.