Livebindings Pro Contra

[bernau]

Habe einiges gesucht und einiges gefunden. Aber so richtig erschliesst sich mir nicht der Sinn von Livebindings.


Habe auch einige Besipiele aus XE2 angesehen.

BindLookupVCLProject -> Kein Code vorhanden. Alles zusammengeklickt.

SynchControlsSampleProject -> Viele Verknüpfungen über den OI. Kaum Quellcode.


Ist das wirklich wünschenswert? Alles nur noch im OI zusammenklicken? Code ist doch viel übersichtlicher. Wenn ich große Projekte habe, kann ich doch kaum noch Fehler anständig finden.

[Sir Rufo]

Meinst du jetzt speziell die LiveBindings oder Binding generell?

[bernau]

Wenn du so fragst: Beides

[Sir Rufo]

Versuch mal mit einem Edit-Control den Form-Titel (Form.Caption) zu bearbeiten (nicht einfach nur setzen, sondern den aktuellen Wert anzeigen zu lassen und dann die Änderung synchron anzuzeigen)

Mit einem Bindung ist das mit ein paar Klicks erledigt.

Mit Code geht das auch (hier mal ein DSharp Beispiel)

Delphi-Quellcode:

procedure TForm1.FormCreate( Sender : TObject );
begin
  TBinding.Create( Self, 'Caption', Edit1, 'Text' );
end;

[mquadrat]

Gerade bei Code wird der Nutzen noch deutlicher. Normalerweise schreibt man haufenweise Glue-Code um die Daten von Objekten in die Controls und wieder zurück zu kriegen. Das nehmen einem die Bindings ab.

Schau dir doch am Besten mal ein paar Tutorials / Blog-Posts zu MVVM an (vorwiegend im .NET Umfeld benutzt). Da kann man sogar über Convention-Over-Configuration die Bindings automatisch erzeugen lassen. Coding = 0.

[stahli]

Hallo bernau,

ich möchte ohne DataBinding nicht mehr arbeiten.

Vielmehr würde ich mir ein noch umfassenderes Framework wünschen, das mir viel notwendige Arbeit abnimmt. Letztlich möchte ich die Daten und Geschäftslogik in einer Schicht (oder in 2 Schichten) bearbeiten und dann eine GUI an diese Ebene(n) "anknüppern".

So hat man klar getrennte Ebenen und kann deutlich übersichtlicher arbeiten.

Irgendeine Berechnung läuft in der Geschäftslogik und wenn das fertig ist, aktualisiert die GUI ihre Darstellung (ohne dass man das bei der Programmierung explizit durchführen muss).

Wie dieses Framework am besten aufgebaut und die Datenbindung geregelt wird (insbesondere in Multi-Tier-Projekten), darüber würde ich gern noch mehr lernen und diskutieren.

Für lokale Anwendungen gibt es ja inzwischen einige Lösungen.
Und auch wenn man die Bindung nicht in der IDE festlegt sondern zur Laufzeit, ist das angenehmer und übersichtlicher als die Daten per Code zu transportieren (Edit.Text := Object.Name und das Ganze zurück).

Mit meinen odControls kann ich in diesem Bereich sehr gut arbeiten, aber für Multi-Tier-Projekte sehe ich noch keinen guten Ansatz. Ich will Dir nix aufschwatzen (zumal ich bei meinem Ansatz inzwischen auch einige Grenzen erkenne), aber Du könntest Dir hier mal das Video "school-02" ansehen.
Es sollte jedenfalls der Vorteil von Schichtentrennung und Datenbindung erkennbar werden...


EDIT:
Die Fehlersuche wird stark vereinfacht, da man sich nur noch innerhalb der Businesslogik bewegt wenn man die Abläufe nachvollzieht. Die Syncronisation der Formularcontrols bleibt an der Stelle außen vor (ich denke jedenfalls, dass das bei Live Bindings und DSharp auch so läuft).

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