Livebindings Pro Contra

[Stevie]

Mal wieder nen Thread nach meinem Geschmack

Wie schon einige erwähnt haben, primärer Nutzen von data binding allgemein ist: man muss keinen extra Code für den Datentransport (im Sinne von, wie kommt der Vorname aus dem Edit in das TCustomer Object) schreiben. Somit entfällt nahezu jeglicher code behind (der Code, den man so üblicherweise in den diversen Control Events findet). Du kannst also hingehen zu Entwickler A, der sich besonders gut mit Oberflächen Design auskennt und ihm sagen, dass du eine Eingabemaske für Kundendaten brauchst. Der kloppt dann die ganzen Controls auf die Form, macht sie hübsch und ist fertig (kann man dann übrigens auch schon gut mit dummy daten als Mockup benutzen). Entwickler B entwickelt derweil die Business Logik, welche Daten sind Pflichtfelder, welche Plausibilitätsprüfungen müssen beim Speichern eines Kunden erfüllt werden, etc pp. Dazu ist zweifellos viel Disziplin und ein gutes Konzept notwendig und man muss sich von diesem - ich nenn ihn immer "klassischen Ansatz" (Controls auf die Form, Events reinklimpern, fertig) trennen.

Was gewinne ich nun dadurch?

Testbarkeit: Ich brauch nicht durch das Form oder die komplette Applikation klicken bis ich am Kundenform angekommen bin und eventuell einen Kunden eintragen, alle Fälle abdecken, etc sondern kann den Source von Entwickler B in einem Unit test testen, da er nix mit Button16 oder Edit34 am Hut hat. Kann alle Plausiprüfungen auf Korrektheit prüfen und vieles mehr.

Wiederverwendbarkeit: Ich brauch in nem anderen Projekt Kundendaten Validierung, aber ohne Oberflächenfirlefanz? Klar, hab ich ja schon, danke Entwickler B.

Austauschbarkeit: Jemandem fällt ein, dass FireMonkey ja viel geiler ist, oder DevExpress, TMS oder ka was Controls viel stylischer aussehen? Ok, stell halt die Eingabemaske von Entwickler A um und fettich.

Ganz klar, das allein erreiche ich nicht durch data binding. Und data binding ist auch nicht das ausschlaggebende. Beschriebene Trennung konnte ich auch schon in Delphi 7 oder früher machen - nur nicht so elegant!


So, und nun zu LiveBindings speziell. Imho sind die Kollegen bei Embarcadero da leider etwas über oder am Ziel vorbei geschossen. Es wurde viel Potenzial verschenkt (compile time safety für string basierte bindings - Fehlanzeige). Die Konfiguration ist leider mal wieder total im RAD Ansatz erstickt. Alles kann man sich zusammen klicken und stecken und hinterher steckt so viel Krempel in der dfm Datei wo keiner mehr nachvollziehen kann, warum oder ob irgendwas nicht funktioniert.

Ich hatte schonmal an anderer Stelle erwähnt: LiveBindings sind imho aus der Notwendigkeit heraus entstanden, für FireMonkey die DBControls Funktionalität nachzubauen. Dabei ist leider das Grundkonzept - nämlich *einfach* Daten von A nach B zu schieben - auf der Strecke geblieben. Wenn man in FireMonkey in nem StringGrid nen FishFacts Dataset anzeigen will, klappt das alles prima. Wenn ich die Daten noch in extra Edits und was weiß ich editieren will, auch. Aber da hörts auch schon mit der einfachen Bedienung auf. Die einfachen TBindExpressions haben keine Funktionalität, automatisch über die Änderung in einem Edit informiert zu werden. Das geht nur in den TBindLink Teilen. Und die arbeiten sehr ungern mit einfachen Datenobjekten oder ner TList<TCustomer> z.B.

Die DSharp Bindings sind auch nur aus der Notwendigkeit heraus entstanden, dass ich ein MVVM Framework bauen wollte, was aber zumindest für mich nur sehr schwer ohne data binding vorstellbar ist - dazu in Kürze übrigens mehr an gewohnter Stelle

Wen diese ganze Thematik interessiert, dem würde ich in der Tat, wie mquadrat schon erwähnte, empfehlen, sich einige speziell in WPF verbreitete Ansätze (vor allem dieses ominöse MVVM ) anzuschauen.

[stahli]

Zitat von Stevie:

dass ich ein MVVM Framework bauen wollte, was aber zumindest für mich nur sehr schwer ohne data binding vorstellbar ist - dazu in Kürze übrigens mehr an gewohnter Stelle

[bernau]

Danke für die Infos. Dann frage ich mal weiter:

Geschäftslogik von der Eingabe zu trennen ist schon ne gute Idee. Aber kann ich mit Lifebindings auch Fehler nach aussen geben. Kann ich mit Lifebindings ein Editfeld mit einer anderen Farbe hinterlegen, wenn der Wert ausserhalb des gültigen Bereiches liegt?

[stahli]

Mit einer nackten Bindung (wie in meiner Lösung) nicht.

Es gibt aber auch Frameworks, die das ermöglichen.
DSharp kann so etwas wohl bereits (habe ich noch nicht konkret getestet), die LiveBindings aber m.W.n. nicht.

In meiner Lösung wird jede Änderung (jeder Tastendruck) sofort in die Datenebene geschrieben. Entsprechend wird auch dort geprüft, ob ein neuer Wert akzeptiert wird oder nicht.
Der Vorteil ist, dass in einem Bearbeitungsformular nicht Kopien von Daten erzeugt werden müssen und Änderungen nachher per OK-Button o.ä. in die Datenschicht geschickt werden. Es gibt also eine strickte Bindung.

Man kann es aber auch so lösen, dass der Client (bzw. die GUI-Controls) die Eingaben prüfen und erst in die Datenebene schreiben, wenn die Validierung positiv war.

Ich weiß nicht ob man generell sagen kann, was der bessere Weg ist. Das hängt vermutlich auch vom Einsatzzweck ab. Bei der strikten Bindung muss man eben weniger in der GUI definieren.

[Medium]

Solche Min- und Maxwertbehandlungen gehören imho auch eher in das anzeigende Control, nicht ins Binding. Also: Ableitung von TCustomEdit nehmen, und das Verhalten dort einbauen. Wenn man die Min und Max-Felder dann auch noch öffentlich hat, ließen die sich auch via Binding steuern

[stahli]

Solche statischen Prüfungen wie Min- und Maxwerte können natürlich im Control erfolgen (wie z.B. in einem SpinEdit).
Anders stellt sich die Frage bei komplexeren Prüfungen, die sich auf die existierenden Daten beziehen (z.B. Prüfung eines eingegebenen Kundennamens oder einer eMail-Adresse).

[Medium]

Das wäre irgendwie ja doch schon wieder Geschäftslogik, weil ggf. Funktionsrelevant.