Hallo,

ich hatte diese Frage schonmal gestellt und mich damals dafür entschieden, dass ich alle Objekte ganz abstrakt definiere (zB Benutzer, Notiz etc.) und ein zentrales Datenbankobjekt erstelle mit den Methoden (Read, Write etc.). Doch jetzt kommen mir ein paar Zweifel auf, ob das auf Dauer wirklich unkompliziert funktioniert.

Wie realisiert ihr den Datenbankzugriff der Objekte, wenn jedes Objekt auf die DB angewiesen ist? Der Unterschied wäre programmiertechnisch folgender:

markieren

Delphi-Quellcode:

//Variante 1: DB-Zugriff nur über DB-Klasse mit Read/Write-Methoden
Notiz:=TNotiz.Create;
Notiz.ID:=100;
db.Read(Notiz); //lädt eine Notiz mit allen Infos wie User, Timestamp usw.

//Variante 2: Objekt hat selbst eine DB-Schnittstelle
Notiz:=TNotiz.Create;
Notiz.LadeNotiz(100); //gleiches, wie bei dem DB-Objekt.

Der Unterschied kommt jetzt:
Wenn ich jetzt eine erweiterte Methode hinzufüge, die mehr oder andere Daten laden soll, dann ist eine einfache Read-Methode zu unflexibel, oder? Entweder wird diese ausgeführt (so wie sie ist), oder eben nicht. Würde das Notiz-Objekt selbst eine DB-Schnittstelle haben, könne man verschiedene Lese-Methoden implementieren, wie zB

Notiz.LadeErweiterteInfos(100); Das Problem ist, dass meine Read-Methoden so aussehen

markieren

Delphi-Quellcode:

...
if (Obj is TNotiz) then
begin
  sql:='...';
  ...
end;

Ich hoffe, dass ich mich nicht allzu dämlich ausgedrückt habe, es ist aber gerade schwer zu beschreiben. Die Kernfrage ist eben, ob jedes Objekt eine DB-Schnittstelle bekommen soll, oder ob das Auslesen aus der DB ein zentrales Objekt übernehmen soll. Wie löst ihr solche Fragen?

Danke im Voraus

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?

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?