FMX + Datenbindung

[AuronTLG]

Ich habe, da ich FMX ausschließlich für Android und IOS verwende, quasi nie die Situation, dass ich Daten in Echtzeit behandeln muss, weswegen ich das manuell mit Queries mache, soll heißen Daten in die Form, dort bearbeiten, dann zurückschreiben bei Schließen oder Button-Click.

Ich hatte mir Live-Bindings mal angeschaut, fand sie aber umständlich, unübersichtlich und in ihren Anwendungsmöglichkeiten zu begrenzt, wie du ja schon festgestellt hast. Müsste ich wirklich Echtzeitänderungen implementieren, so würde ich das vermutlich tatsächlich manuell machen, zumal ich in derselben Zeit, in der ich mich durch den Livebinding-Assistenten geklickt habe, das Ganze auch manuell umgesetzt habe.
Da es dabei ja wie gesagt um Smartphone-Apps geht, hält sich der Aufwand zumeist eh in Grenzen und mit Datenbank/Nutzer-Konflikten auseinandersetzen fällt auf dem Smartphone ja ebenfalls weg.

Müsste ich eines meiner Desktopprogramme in FMX umsetzen, so würde ich mich fachmännisch erschießen.

[TigerLilly]

Fachmännisch erschießen ist gut. Lach.

Naja, Echtzeit und Datenbank/Nutzer ist gar nicht so sehr das Thema, dazu gibt es ja Datasets, ORM und so - das ist schon ok. Ich frage mich, wie die Daten halbwegs komfortabel aus dem Dataset in die Controls am Form kommen und die Änderungen wieder zurück.

@AuronTLG: Du machst das (Datenfeld nach Control) manuell? Jedes einzeln?

[AuronTLG]

Jo, finde ich ehrlich gesagt auch nicht so aufwendig.

"XYZ.Text := Query.FieldByName('XYZ').AsString;" bzw "XYZ.Params.ParamByName('XYZ').AsString := XYZ.Text;" sind schneller geschrieben als wenn man sich stattdessen durch den Live-Binding-Assistenten durchklickt.

Wie gesagt, sind ja Smartphone-Apps. Da hat eine Form vielleicht mal 5-10 Eingabefelder, wenn überhaupt. Müsste ich das so für eine meiner VCL-Formen mit 50-100 Schaltflächen machen, wäre das schon deutlich nerviger und spätestens bei mehreren solcher Formen würde ich dann wahrscheinlich über eine Automatisierung nachdenken, welche das Verhalten von DB-Komponenten simuliert.

[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.