Datenbankobjekt in allen Objekten oder zentral?

[Iwo Asnet]

Wie wäre es, für jede Storage-Engine eigene Reader/Writer-Klassen zu erstellen, z.B.

TSQLNotizReader, TSQLNotizWriter
TXMLNotizReader, TXMLNotizWriter
TBinaryNotizReader, TBinaryNotizWriter
...

Vorteil: Skalierbar, denn egal wie viele neue Datenklassen, oder Storageengines du hast, keine vorhandene Reader/Writer-Klasse muss deshalb angefasst werden.

Du kannst dann mit einer Classfactory sehr elegant deine Daten lesen und speichern, denn die Schnittstelle vom Reader/Writer ist ja immer gleich. Heute nimmst Du eine DB, morgen XML, übermorgen Firebird, und nächste Woche mal Oracle. Oh, NoSQL ist gerade in => na und?

[TheMiller]

Danke für die Antwort.

Du hast da schon recht. Nur meine Projekte speichern ausschließlich die Daten in einer Datenbank. Entweder Firebird, MY/MSSQL. Dafür habe ich eine globale Klasse DBBase, von dieser habe ich dann - wegen den syntaktischen Unterschieden - jeweils eine RDBMS-Klasse erstellt. Also TMySQLDB -> geerbt von DBBase.

Aber die Frage ging eigentlich in die Richtung, ob ich ein getrenntes Datenbankobjekt benutzen soll (so wie es gerade der Fall ist), oder soll jedes Objekt wie eine Notiz oder ein Benutzer eine Schnittstelle zum Datenbankobjekt bekommen. Vorteil wäre, dass man dann vom Objekt aus direkt die DB steuern kann (TBenutzer.Login). Ist flexibler, aber irgendwie nicht korrekt, weil sich die Datenbankzugriffe auf alle Objekte "verstreuen" und man im Ernstfall alle Objekte ändern müsste. Oder?