FMX + Datenbindung

[TigerLilly]

Mich würde interessieren wie Ihr das macht.

Ich habe Daten in einer Datenbbank und möchte die letztendlich in einem Formlular zur Bearbeitung darstellen. Unter der VCL hätte ich einfach datensensitive Komoponenten genommen. Die gibt es ja untzer FMX nicht.

Alternativen: Live Bindings, die gehen aber zB mit einigen TMS Komponenten nicht. SmartBindings von Components4Developer, die sind aber irgendwie clumsy. Ich könnte PODs machen und Transferroutinen zum Hin und Herschaufeln + Observer zum Reagieren auf Änderungen. Ab er da entsteht irgendwie jede Menge Boilerplate Code.

Wie macht Ihr das?

Danke für jeden Input.

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