[Tutorial] Laden / Speichern von Objekten in einer normalisierten Datenbank

[Rollo62]

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

Die sollen das doch genau das Daten- und MemoryManagement vor mir Kapseln.

ORM ist gut und richtig, das sehe ich auch so.
Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?
Warum unbedings Objekte dazwischenbauen ?
(Ok, ich verstehe das man in den Objekten tolle Logik reinbauen kann, aber sollte man das wirklich dort machen) ?

Mit einer Wrapperklasse sollte das doch "einfach" möglichs ein.
TDbGrid macht das doch im Prinzip auch so, nur der der Wrapper im DBGrid selber ist, sozusagen.

LiveBinding per Code macht das im Prinzip so, mit FillExpressions z.B. für ListView,
und da glaube ich eben auch das dies der richtige Weg ist, das per RTTI zu entkoppeln.

So in dieser Richtung, am liebsten per Code:

Delphi-Quellcode:

   FDb.Bind(Query1, ListView, 'Name',  'Text')
      .Bind(Query1, ListView, 'Descr', 'Detail')
      .Bind(Query1, ListView, 'ImgId', 'ImageIndex')
      .Bind(Query1, Grid1,    '*')
      .Bind(Query1, Edit1,    'Name',  'Text',  dbBidirectional)
      ...
      ;

Rollo

[Uwe Raabe]

Zitat von Rollo62:

Ich binn dann wohl immer noch im Irrglauben das die Datasets nicht Alle Daten im Speicher halten, sondern nur intelligent per Chinks sich die passenden Häppchen holen.

Das hängt sicher vom Query ab, ein FDMemTable oder ClientDataSet hat Alles im Speicher,
aber was ist mit TFDQuery, oder ähnlichen Konstrukten ?

TFDQuery holt sich zwar die Daten häppchenweise, behält diese aber im Speicher - außer, es ist Unidirectional aktiv, dann werden die bereits besuchten Datensätze wieder aus dem Speicher geworfen.

Bezüglich ORM und DataSet/DBControls: Bei TMS Aurelius gibt es extra ein TAureliusDataset um die beiden Welten wieder zu vereinen.

[haentschman]

Zitat:

Aber warum eigentlich nicht direkt von TDataset auf die Controls binden ?

1. u.a. Faulheit. Ich habe die Faxen von ständig Query.FieldByName('FBlubb').AsInteger voll.
2. Weil ich die Daten im DataSet nicht strukturieren kann. Ähnlich einer Ordnerstruktur.

Zitat:

Warum unbedings Objekte dazwischenbauen ?

1. Im Quelltext steht kein einziger Feldname.
2. Die Datenbank oder die Datenquelle ist komplett getrennt. Die Daten können über das Interface aus Oma´s Küchenschrank kommen. Der Küchenschrank kennt kein DataSet sondern XML...
3. Das macht das Wechseln zwischen den Datenbanken / Quellen einfacher. Getrennte Statements je Interface für die verschieden DBMS.
4. Am Breakpoint kann man sich das komplette Objekt mit seinen Daten ansehen.

eine Bitte:

Zitat:

Bei TMS Aurelius gibt es

...das wir in diesem Tutorial nur über dieses Beispiel ORM diskutieren. Danke.

[Rollo62]

Wenn ich das richtig sehe hast du keine Interaktion drin, die Controls werden gefüllt.
Der Spass fängt aber dann an wenn du ein Grid oder Listview scrollen und editieren möchtest,
wenn Master-Detail sich synchronisieren müssen, korrekt die Daten in die DB zurückschreiben, etc..
Das müsste ja meiner Meinung nach auch gekapselt werden, das will man nicht immer wieder neu schreiben müssen.
Ich sehe das so das es eine Art "Bindings" in irgendeiner Form geben müsste, zum einen für die Daten (so wie du es hast z.B.), zum anderen eben diese Events (abhängig vom jeweiligen Control
und "Style" der Bedienung).

Wie würdest du denn so etwas bei deinem Vorschlag lösen ?

Rollo

[Fritzew]

Danke für das Tutorial.
Da es nicht nur ORM sondern auch Interfaces behandelt, oder besser gesagt auch zeigt wie die Benutzung aussehen kann, finde ich es wirklich gut.
Klar gibt es da viele verschiedene Ansätze, aber um aufzuzeigen wie man etwas auch anders machen kann finde ich es toll.
Was mit immer wieder auffällt in unserer "Delphi" Welt, ist das neue Ansätze es hier wirklich schwer haben.

[p80286]

Erst einmal vielen Dank!

Für den Datenbank-Teil hätte ich noch die eine oder andere Idee, aber das wären nur Detailänderungen, die mir pers. besser in den Kram passen würden. Den Interface-Teil habe ich zwar verstanden, glaube ich, aber der Vorteil erschließt sich mir nicht so recht. Mit einem TDataModule kommt man (ich) genauso weit, einziges Problem(?) für jede DB brauch ich ein eigenes Modul aber ein MyDM.GetPersonList(pl:tPersonlist) sollte immer die (formal) gleiche Liste liefern.

Gruß
K-H

[haentschman]

Moin...

Zitat:

Danke für das Tutorial.

Zitat:

Erst einmal vielen Dank!

...Dankeschön.

Zitat:

Der Spass fängt aber dann an wenn du ein Grid oder Listview scrollen und editieren möchtest,

Zitat:

Wie würdest du denn so etwas bei deinem Vorschlag lösen ?

Persönlich habe ich mich entschieden, daß niemals in der Listview editiert wird. Das hatte den Grund, daß mehr Informationen zu editieren waren als Spalten optisch zur Verfügung standen. Zum Editieren blende ich einfach eine modale Form über die Listview ein. Ich nenne sie InlineEditor. (siehe Bild 1) Damit kann ich beliebige Informationen editieren und die Controls im InlineEditor selbst, auch wegen der Optik, festlegen. Dem InlineEditor wird das Objekt, welches am Listvieweintrag hängt, übergeben...usw. (siehe Bild 2) Am Objekt kann man sehen, daß das mit dem Dataset nicht übersichtlich möglich ist. Das Objekt würde eigentlich aus mindestens 3 Datasets bestehen.

Zitat:

Das müsste ja meiner Meinung nach auch gekapselt werden, das will man nicht immer wieder neu schreiben müssen.

Der Kreativität sind keine Grenzen gesetzt. In meinen Produktivprojekten ist einiges als gemeinsamer Code ausgelagert um nicht alles neu schreiben zu müssen. Beispiel. Der InlineEditor. Den leite ich von der Basis, mit aller Logik für die Anzeige etc., ab.
...aber das würde zu weit führen und hat nichts mit dem Thema zu tun.

Zitat:

aber das wären nur Detailänderungen, die mir pers. besser in den Kram passen würden.

Der Kreativität sind keine Grenzen gesetzt. Du kannst das Prinzip für deine Bedürfnisse anpassen.

Zitat:

sollte immer die (formal) gleiche Liste liefern.

...das ist korrekt.

Zitat:

Mit einem TDataModule kommt man (ich) genauso weit, einziges Problem(?) für jede DB brauch ich ein eigenes Modul

1. Wenn eh keine Querykomponenten auf dem DataModule liegen kannst du dir das auch sparen. Prinzipiell kommst du auch mit einem DataModule für eine Datenbank zurecht. Wenn du ein neues DBMS dazunimmst, kommst du um eine Abstraktion nicht herum.

Delphi-Quellcode:

// Klassendefinition oder so ähnlich
TDataBaseAbstract = class
public
  procedure Blubb; abstract;
end;
...
TDataBase1 = class(TDataBaseAbstract)
public
  procedure Blubb; override; // die spezielle Implementierung für Blubb
end;
...
TDataBase2 = class(TDataBaseAbstract)
public
  procedure Blubb; override; // die spezielle Implementierung für Blubb
end;

// Instanz
FDatabase: TDataBaseAbstract;
...
FDatabase := TDataBase2.Create; // oder so...

...die Vorteile von Interfaces wurde schon an anderer Stelle diskutiert. http://www.delphipraxis.net/192364-t...nterfaces.html