Aber wenn ich einen Datenbank auf mache, hätte ich gerne die Daten im Memory und dann kann ich die Daten bei Bedarf
darstellen.
Nichts anderes passiert bei einem TDataSet und datensensitiven Controls. Das TDataSet hält die Daten (oder einen Teil davon) im Memory und die datensensitiven Controls übertragen das z.B. bei einem TDBEdit in das Text Property zur Anzeige und gegebenenfalls Änderung. Danach werden die Daten aus dem Text wieder in den Puffer des TDataSet übertragen (entfällt natürlich bei nur darstellenden
DB-Controls), von dem das dann beim Post in die Datenbank geschickt wird. Mit dem Enabled der verbindenden TDataSource kann man diese Automatik auch nach Bedarf aus- und wider einschalten. Gleiches geht über das TDataSet mit DisableControls und EnableControls für alle Verknüpfungen.
Nirgendwo geschieht die Datenhaltung in den visuellen Controls. Ob ich jetzt ein TEdit in einer Load-Methode aus einem TField befülle und in einer Save-Methode den aktuellen Inhalt in das Feld zurückschreibe oder gleich ein TDBEdit verwende, das dies automatisch macht (genauer gesagt macht es ein TFieldDataLink), ist doch im Prinzip erstmal egal. Der
DB-Ansatz kommt halt ohne zusätzlichen (also nicht in der Standard-Lib vorhandenen) Code aus.
Interessant finde ich auch, dass einige ORM-Frameworks, wie z.B. Aurelius oder Spring4D, eine TDataSet-Komponente mitbringen, die eine Liste von Objektinstanzen verwaltet. Damit lassen sich datensensitive Komponenten auch auf reine in-memory Objekte anwenden.
Eigentlich waren datensensitive Komponenten von Anfang an ein Weg, die Datenhaltung aus den visuellen Controls auszulagern, noch bevor das als erstrebenswert in den Köpfen der Entwickler verankert wurde. Woher die Ansicht kommt, dass datensensitive Komponenten die Daten selbst speichern, kann ich auch nicht sagen. Es ist definitiv nicht so. Aber Fakes verbreiten sich ja bekanntermaßen leichter als Facts.