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 :coder:

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

Zitat von Mavarik (Beitrag 1519620)

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:

Zitat von Mavarik (Beitrag 1519620)

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:

Zitat von Uwe Raabe (Beitrag 1519633)

Zitat:

Zitat von Mavarik (Beitrag 1519620)

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:

Zitat von Mavarik (Beitrag 1519637)

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:

Zitat von TigerLilly (Beitrag 1519668)

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.

[TigerLilly]

Zitat:

Zitat von Uwe Raabe (Beitrag 1519672)

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

Ich denke mir ja, dass es wohl irgendeinen Grund gibt, das genauso gemacht zu haben. Mir erschließt es sich halt nur nicht. Legacy Anwendung umstellen ist immer wieder ein Thema + Crossplatform ist dann immer auch ein Thema. Aber der Umstieg von VCL zu FMX ist schon ein großer Schritt.

[Uwe Raabe]

Zitat:

Zitat von TigerLilly (Beitrag 1519611)

Alternativen: Live Bindings, die gehen aber zB mit einigen TMS Komponenten nicht.

Kannst du die bitte mal nennen? Die Live-Bindings basieren auf dem Observer-Pattern, das schon seit geraumer Zeit tief in TComponent verankert ist. Damit mache ich an anderer Stelle auch so einiges. Wenn also Komponenten eines Drittherstellers das immer noch nicht unterstützen wäre das meiner Meinung nach ein massives Versäumnis und ich wüsste dann gern vorher wo es haken könnte.

[TigerLilly]

Ich bin bei den FNC Komponenten darüber gestolpert - kann gut sein, dass das für die FMX Komponenten nicht gilt, das müsste ich nachsehen.

Zitat:

Livebindings isn't enabled for FNC. The only 2 components that are currently DB-Aware are TMS FNC Planner and TMS FNC Grid and this functionality is exposed via database adapter. We'll investigate if we can add support for this.

Bei den FNC Komponenten sind die TFNCEdits (mittlerweile) LiveBindings enabled, aber andere eben nicht.

Es gibt von TMS einer DataBinder für FNC, aber der ist nur ReadOnly, schreibt also nicht zurück.

Zitat:

Note that the databinder component is currently only
supporting retrieval and display of data.