FMX + Datenbindung

[Mavarik]

Ich verwende NIE und hab auch noch NIE Datenbankkomponenten verwendet...

Bei einer Datenhaltung in visuellen Komponenten stäubt sich bei mir alles...
Und auch keine Livebindings.

Eine Klasse die Aufgund der Datenbankinfos eine Datenhaltungsklasse belegen kann (ORM) am besten Referencecounted...
Dann ein Framework das diese Daten bei Bedarf an die Komponenten weiter geben kann... (Will keine Werbung machen)

Aber bei einer App ist es auch eher so: (Die drei Felder kann man per Hand belegen)

Mavarik

[Rollo62]

Unter FMX setze ich DB nur spärlich ein.
Dazu nutze ich LiveBindings, welche ich mit speziellen Wrappern per Runtime und mit FireDAC benutze.
Funktioniert ganz gut und zuverlässig, aber wie schon gesagt für Größeres hätte ich da auch so meine Bedenken.
Mit LiveBindings via DesignEditor in der IDE werde ich wohl nicht mehr warm.

[TigerLilly]

Zitat von Mavarik:

Ich verwende NIE und hab auch noch NIE Datenbankkomponenten verwendet...
Bei einer Datenhaltung in visuellen Komponenten stäubt sich bei mir alles...

Naja, in der VCL sind die DB sensitiven Komponenten samt Dataset/source je genau "ein Framework das diese Daten bei Bedarf an die Komponenten weiter geben kann".

Zitat:

Eine Klasse die Aufgund der Datenbankinfos eine Datenhaltungsklasse belegen kann (ORM) am besten Referencecounted...

Macht für mich Aurelius.

Zitat:

Dann ein Framework das diese Daten bei Bedarf an die Komponenten weiter geben kann... (Will keine Werbung machen)

Mach ruhig Werbung.

[Uwe Raabe]

Zitat von Mavarik:

Bei einer Datenhaltung in visuellen Komponenten stäubt sich bei mir alles...

Na ja, wenn du die Darstellung eines Datenstrings in einem TCustomEdit schon als Datenhaltung in visuellen Komponenten verstehst, dann wird das mit der visuellen Darstellung von Daten aber schwierig.

Die datensensitiven Komponenten machen auch nichts anderes als die Daten bei Bedarf aus dem entsprechenden TField zu holen und diese wieder dort abzulegen, wenn sie in der visuellen Komponente verändert wurden (und noch ein bisschen was drumherum mit Formatierung und Prüfung und so, was einem die Arbeit schon gelegentlich deutlich erleichtert).

Ich benutze datensensitive Komponenten schon seit Delphi 1 und werde das auch weiter tun, wenn das eine brauchbare Lösung für das gerade aktuelle Problem sein sollte. Natürlich verwende ich auch andere Ansätze (z.B. meinen Dataset Enumerator, auch in Kombination mit datensensitiven Komponenten), immer den jeweiligen Anforderungen entsprechend. Datensensitive Komponenten von vornherein auszuschließen finde ich schon etwas - sagen wir einengend.

Übrigens benutze ich auch schon immer statische Datenbankfeldkomponenten, weil es eben viele Möglichkeiten (zumindest einfacher) bietet, in den datensensitiven Prozess einzugreifen. Die immer wieder auftauchende Abneigung dagegen kann ich nur einer unvollständigen Kenntnis der Zusammenhänge zuschreiben. Oder es ist einfach nur Geschmackssache.

Probleme machen natürlich immer die neuen Komponenten, für die es (noch) kein datensensitives Pendant gibt. Auch dafür gibt es Lösungen, die man nach einmaligem Erstellen immer wieder einsetzen kann. Ein umfassendes Beispiel habe ich vor ein paar Jahren hier beschrieben: CodeRage Deutschland 2019 - Session 06 - Zwischen DB-Controls und LiveBindings

Bisher hat sich noch keine Notwendigkeit ergeben, aber ich bin fast sicher, dass sich dieses Konzept mit etwas Geschick auch auf FMX anwenden lässt.

[Papaschlumpf73]

Ups, falsch zitiert - war auch nicht so wichtig.

[Mavarik]

Zitat von Uwe Raabe:

Zitat von Mavarik:

Bei einer Datenhaltung in visuellen Komponenten stäubt sich bei mir alles...

Na ja, wenn du die Darstellung eines Datenstrings in einem TCustomEdit schon als Datenhaltung in visuellen Komponenten verstehst, dann wird das mit der visuellen Darstellung von Daten aber schwierig.

Natürlich nicht...
Aber wenn ich einen Datenbank auf mache, hätte ich gerne die Daten im Memory und dann kann ich die Daten bei Bedarf
darstellen.

[Uwe Raabe]

Zitat von Mavarik:

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.

[Papaschlumpf73]

Uwe hat es mal wieder auf den Punkt gebracht. 👍

[TigerLilly]

Mich wundert es sehr, dass es da aus Entwicklersicht von der VCL zu FMX so einen - nun - Rückschritt gegeben hat. Ich müsste im Augenblick drei unterschiedliche Technologien (oder zwei und selber was schreiben) mischen, um das zu bekommen, was bei der VCL out of the box ging.

Und ja: Ich habe ein sehr datenlastiges Programm, das ich gerne Multi-Platform machen würde. Ich bin da grad ratlos.

[Uwe Raabe]

Zitat von TigerLilly:

Mich wundert es sehr, dass es da aus Entwicklersicht von der VCL zu FMX so einen - nun - Rückschritt gegeben hat.

Ja, das wundert mich auch. Insbesondere hätte man hier gleich die Datensensitivität ganz am Anfang der Vererbung vorsehen können. Das hätte die separaten DB-Controls ganz erspart. Man hat ein DataSource und ein DataField Property (letzteres wird nicht überall gebraucht). Ist das DataSource Property nil verhält sich das Control normal, andernfalls eben datensensitiv. Beide Properties sind erstmal protected und werden in den jeweiligen Controls dann nach Bedarf published.

Es hätte so einfach sein können. Stattdessen steckt man die Entwicklerkapazitäten in Live-Bindings.