Pro/Contra Virtuelle Tabelle oder TObjectList

[norwegen60]

Hallo zusammen,

mich würde interessieren, ob es entscheidende Vor-/Nachteile zwischen einer virtuellen Tabelle (z.B. TJvMemoryData) oder TObjectList gibt.

Auf die virtuellen Tabellen bin ich gestoßen, weil ich die Daten der aktuelle bestehenden TObjectList(en) in QuickReport ausgeben muss. Der einfachste Weg schien mir, die TObjectList in eine TJvMemoryData zu speichern. Die wird dann von den TSubDetail-Bändern genau gleich behandelt wie die normalen Datenbank-Tabellen.

Warum ich überhaupt TObjectList verwende?
Weil die Datenstruktur der gegebenen Datenbank grauenhaft ist und ein Umstellung ist aufgrund Datenintegrität nahezu unmöglich. Von daher haben wir ein Klassenbaum aufgebaut, der die Daten verwaltet. Nur beim Einlesen und der Ausgabe müssen wir uns mit der DB beschäftigen. Hat auch den Vorteil, dass wir von der DB unabhängig sind wenn die Daten mal eingelsen sind. Ein Test läuft also auch dann weiter, wenn sich die DB mal abhängt.

Bisher habe ich nie virtuelle Tabellen eingesetzt. Deshalb die Frage, welche Probleme zu erwarten sind. Oder gibt es bessere Alternativen als TJvMemoryData.

In einem neueren Projekt könnte ich auch auf TUniDac zurückgreifen. Das wird in diesem Projekt aber nicht eingesetzt. Falls deren TVirtualTable aber erheblich Vorteile bietet, könnte man darüber nachdenken, UniDac zu verwenden.

Was mich ein bisschen stört, ist dass die Daten jetzt zweifach vorhanden sind. Immer in der TObjectList und beim Drucken auch noch in JvMemoryData.

Das ganze Projekt ist noch Delphi XE

Grüße und Danke für Feedbacks

Gerd

[Stevie]

Gibt mMn kein entweder oder - sowas wie TJvMemoryData o.ä kann genutzt werden, um bereits in anderer Form vorhandene Daten von Dingen zu konsumieren, die mit TDataSet arbeiten - z.B. Grids.

Falls die Daten sowieso direkt aus der Datenbank kommen, und dafür erst Objekte gebaut werden, die dann in eine Liste gepackt werden, die dann über ein TJvMemoryData an einen Report gegeben werden, ist das möglicherweise durchaus ungünstig und es wäre besser, die Daten direkt in einem Dataset aus der Datenbank zu saugen und an den Report zu geben.

TL'DR: Es kommt drauf an

[himitsu]

Also ich lese überall immer raus
* ORM und wildes Databinding mit vielen gutklingenden Zwischenschichten ist cool
* und DataSets sind sowas von vor 80 Jahren

Zitat:

Falls die Daten sowieso ...

Das wäre ja viel zu einfach und nicht modern genug,
nja, warum einfach und direkt, wenn man auch viele Umwege machen kann.

[bcvs]

Die Daten sind aber anscheinend eh schon in TObjectListen. Da würde ich den QuickReport direkt aus der TObjectList füttern, gesteuert über den OnNeedData - Event.

[norwegen60]

Wie schon gesagt, sprechen zwei Gründe gegen die direkte Anbindung per Datasets

• Die Datenstruktur ist dazu völlig ungeeignet. Weiter möchte ich darauf nicht eingehen, denn das ist leider gegeben
• Durch das einlesen in eien Klassenstruktur kann die DB auch mal Offline sein ohne dass die Anwendung bockt.

Der Ansatz über OnNeedData ist interessant, erscheint mir auf die Schnelle aber aufwändiger, als das einlesen der Daten in eine virtuelle Tabelle. Die kann ich dann sowohl für die Ausgabe in ein Grid, in einen Chart oder in QuickRep verwenden. Mit der VirtualTable kann ich dann einfach im Object-Inspector den TQRDBText-Feldern die Tabellen-Felder zuweisen.
OnNeedData benötigt wohl so was in der Art:

Delphi-Quellcode:

  QrLabel1.Text := IntToStr(Liste[i].Nr);
  QrLabel2.Text := Liste[i].Name;
  QrLabel3.Text := Format('%5.3f',[Liste[i].Wert]);

Das ist dann doch mehr Aufwand wenn man das mal für QuickReport, mal für ein Grid und das näcshte mal für ein Chart macht.
Oder übersehe ich was.

Was klar dagegen spricht ist die Mehrfachhaltung der Daten.

Im Grunde ging es mir auch eher darum, ob es bei VirtualTables Besonderheiten gibt die zu beachten wären, bzw. ob es generelle Vor-/Nachteile gibt.

[himitsu]

Zitat:

Die kann ich dann sowohl für die Ausgabe in ein Grid, in einen Chart oder

Wenn du mal in Richtung Firemonkey guckst, dann ist TList, Array oder DataSet kein großer Unterschied, da du alles erst über einen Adapter an die Oberfläche databindest.
(k.A. wie ob/wie QuickReport dort arbeitet)

Im Prinzip kann man auch für TDataSet einen Adapter schreiben, egal ob FMX oder VCL, wo ein DataSet intern auf die Daten einer (Objekt)Liste zugreift, anstatt auf ein DBMS.

[haentschman]

Moin...

+ Objektlist

Begründung:
1. imho ist im DataSet (FireDAC) zu viel Overhead drumherum.
2. Durch eine Objektliste kann man iterieren ohne daß sich die Oberfläche bewegt! (wegen anderer Methoden die Daten anzuzeigen)
3. Dataset: Keine Strukturen wie in einer Klasse. Sinngemäß in einer Klasse Master / Detail (Liste)
4. In eine Klasse kann ich hinein gucken (Debug)...in ein Dataset mit Debug nicht (nur mit Hilfstools)

Zitat:

Zwischenschichten ist cool

...ist cool. In der Zwischenschicht kannst du entscheiden wo die Daten herkommen...Datenbank, CSV, REST oder gemischt...die Anwendung kennt nur die aus der Zwischenschicht "gebauten" Objekte. Ich für meinen Teil löse Dataset in der Anwendung ab. Umbau auf Objekte in der BL.

my 2 Cent...

[freimatz]

Zitat von himitsu:

ORM und wildes Databinding mit vielen gutklingenden Zwischenschichten ist cool

nope. ORM und durchdachtes Databinding mit ausreichend Zwischenschichten ist cool

Warum eigentlich konkret TJvMemoryData? Es gibt doch noch etliche andere Memory Datasets.

Und wenn schon TObjectList, dann TObjectList <>
Meine 42 cents

[jaenicke]

Zitat von haentschman:

4. In eine Klasse kann ich hinein gucken (Debug)...in ein Dataset mit Debug nicht (nur mit Hilfstools)

Dafür habe ich mal eine IDE Erweiterung geschrieben, die sich wie die TStrings-Ansicht beim Debuggen verhält und ein DBGrid anzeigt, wenn man auf diese Weise ein Dataset auswertet.

[haentschman]

Zitat:

Dafür habe ich mal eine IDE Erweiterung geschrieben, die sich wie die TStrings-Ansicht beim Debuggen verhält und ein DBGrid anzeigt, wenn man auf diese Weise ein Dataset auswertet.

..her damit. Ich habe nur ein Tool was Quasi ein Fenster öffnet...dafür immer den QT dafür ändern.

Ich wollte mal eine Visualisierung dafür machen...ich hab einfach keine Zeit.

Zitat:

Und wenn schon TObjectList, dann TObjectList <>

...versteht sich von selbst wenn man Generics hat.