[...] 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.
Anything, carried to the extreme, becomes insanity. (Exilant)