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.