DataSet und die Datenbanklogik

[Hansa]

Im grossen und ganzen stimmt das so schon. Nur was soll das :

Zitat von exilant:

Vergiss Tdataset und seine hässlichen (TTable-) Kinder.

Die TTable-Kinder soll er wirklich vergessen, aber was hat das mit TDataSet zu tun ? Das ist die gemeinsame Grundlage. Bei TTable siehts jetzt so aus : erben tut das von TDBDataSet, das von TBDEDataset und letztendlich von TDataset. Das TDataSet kann man sowieso nicht einfach so benutzen, sondern nur die entsprechenden Ableitungen. Was soll man denn überhaupt benutzen, wenn nicht von TDataSet abgeleitete Komponenten ? Z.B. das : TpFIBDataSet Welche Alternative gibt es denn dazu ? Und wo kommt das her ? Richtig von TDataset bzw. bei Delphi 10+ von TWideDataset.

Das TDataSet ist deshalb so wichtig, um die Kompatibilität zu wahren. Wer sich nicht mal daran hält, der wird auf mittlere Sicht Schiffbruch erleiden. Siehe IBObjects. Lange nichts mehr davon gehört (Zeos nicht auch ? ). Aber im Endeffekt trotzdem logisch. Die TdataSet-Inkompatibilität hat dafür gesorgt, dass es sehr sehr viel Arbeit gibt. Mir wärs auch zu blöd das Rad jedesmal neu zu erfinden (z.B. TMyDbGrid + Co.) und noch an jede neue Delphi-Version anzupassen.

[nachti1505]

Für Anfänger besteht hier aber ganz schnell die Gefahr (wie oben beschrieben), dass durch die Kette TDataset->TDataSource->TDBGrid ganz schnell MVC verlassen wird. Und das später wieder gerade zu biegen... na ja, ich weiß was das bringen kann!

[Hansa]

Zitat von nachti1505:

dass durch die Kette TDataset->TDataSource->TDBGrid ganz schnell...

Das ist zumindest keine Vererbungs-Kette, wie von mir beschrieben. Siehe hier : TDataSource = class(TComponent) Das sind lediglich Properties, die zugewiesen werden können und sonst nichts. Vererbt wird da nichts.

[mkinzler]

Zudem ist die Richtung falsch.

[Hansa]

Zitat von mkinzler:

Zudem ist die Richtung falsch.

Kommt aber auch drauf an, in welcher Richtung man liest. Habe mir allerdings nochmals die Ausgangsfrage durchgelesen. Da werden TIBTables benutzt ? Wieso steht dann im Titel was von DataSet ? Wie bereits gesagt : das ist ein nicht zu unterschätzender Knackpunkt. Dann noch zu den Events und IBX, rückgelieferter ID usw.: habe da ein ungutes Gefühl. Zumindest letzteres war definitiv zur Zeit des Auseinanderlaufens von Interbase und Firebird noch nicht da. Ob das mit den Interbase (also IBX)-Komponenten richtig geht ? Ich wäre sehr sehr vorsichtig mit allem, was im Zusammenhang mit Firebird, in Interbase 6.0 noch nicht ging !!

[mkinzler]

Das Grid weist aber auf die DataSource und diese auf das DataSet

[nachti1505]

Zitat von mkinzler:

Zudem ist die Richtung falsch.

TDataset->TDataSource->TDBGrid

Aus der Nutzung von TDataset folgt, der Entwickler setzt noch ein TDataSource auf das Formular und aus der Nutzung der TDataSource folgt, der Entwickler nutzt ebenfalls das (bspw.) TDBGrid! Und schon hat man alles auf einem Forumlar, ganz entgegen dem MVC?

Ich wollte damit nur ausdrücken, dass meine Projekte eine zeitlang gelitten haben, nachdem ich das TDataSet (bzw. deren Nachfahren) entdeckte! Eben wegen oben genannter Kausalkette...

[ot]
Wie würdet ihre denn den Operator "aus x folgt y" darstellen, wenn nicht so "-->"?
[/ot]

[Moebius97]

Hallo nochmal,
ich unhöflicher Mensch! Ich wollte hier nur nochmal
1. mich für die Antworten bedanken.
2. Dadurch fühlte ich mich darin bestärkt, Abstand von den Daten gebundenen Komponenten zu nehmen und die Mehrarbeit zu investieren. Erste Versionen laufen, und es sieht so aus, als könnte ich damit weiter entwickeln.
Veilen Dank und schöne Grüße,

Mario

[exilant]

Zitat von Hansa:

[...] Das TDataSet ist deshalb so wichtig, um die Kompatibilität zu wahren. Wer sich nicht mal daran hält, der wird auf mittlere Sicht Schiffbruch erleiden. Siehe IBObjects. Lange nichts mehr davon gehört (Zeos nicht auch ? ). Aber im Endeffekt trotzdem logisch. Die TdataSet-Inkompatibilität hat dafür gesorgt, dass es sehr sehr viel Arbeit gibt. Mir wärs auch zu blöd das Rad jedesmal neu zu erfinden (z.B. TMyDbGrid + Co.) und noch an jede neue Delphi-Version anzupassen.

Man braucht TDataset nicht um "die Kompatibilität zu wahren". Man braucht TDataset schlicht garnicht.
Die ganzen TDB* Komponenten sind böse. Sie lösen wie schon gesagt das MVC auf. "Good practice" ist es, Daten mittels eines leichtgewichtigen Querys (unidirektional, nicht "lebendig", dafür aber schnell) in geeignete Datenstrukturen (Klassen, Listen von Klassen) einzulesen und via UPDATE und INSERT Statements entsprechender Methoden zu aktualisieren. Damit werden Abhängigkeiten vom DBMS, von GUI Komponenten und im weitesten Sinne sogar von der Programmierumgebung verhindert. Genau die Falle die Du oben beschreibst wird vermieden. Mr. Whartons IBObjects Problem war, nicht erkannt zu haben das Datasets ein Irrweg sind. IBObjects wollte wie die BDE sein, nur "besser".
Die Anzeige der Daten ist eine andere Baustelle. Statt TDb* benutzt man nicht-datengebundene Controls zur Visualisierung/Editierung. Das bringt flexibilität und Geschwindigkeit. Das rumhantieren auf "Tables" bzw. "Live Querys" ist eine Unart der ich zu Clipper/dBase Zeiten auch mal gefrönt habe. Und meine ersten Delphi/BDE Anwendungen sahen auch so aus. Aber die Zeit ist nicht stehen geblieben. Die 80er und 90er sind vorbei. Spätestens beim Einsatz fortgeschrittener Techniken wie ORMs kann man Datasets eh' vergessen. Ich kann wirklich nur jedem raten, sich von TDatsets fernzuhalten.