Livebindings Pro Contra

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

[Uwe Raabe]

Was mich bei der geforderten strikten Trennung von GUI und Geschäftslogik stört: man muss teils komplexe Mechanismen implementieren um auf etwaige Verletzungen dieser Logik in der GUI angemessen zu reagieren. Es genügt ja nicht, einfach nur die Überprüfung in das Businessobjekt zu verlagern, sondern man muss in der GUI ja auch auf die jeweiligen Fehler unterschiedlich reagieren. Andernfalls hat man nur ein stumpfsinniges Eingabeformular, wo doch die intelligente Unterstützung des Benutzers bei der Eingabe eigentlich Standard ist. Dies unterscheidet schließlich eine dumme Anwendung von einer benutzerfreundlichen.

Code in Forms kann m.E. demnach auch bei vorhandener Datenbindung nicht völlig verschwinden. Wenn ich z.B. ein Eingabefeld blinken lassen will, dann macht es keinen Sinn, dies in der Businesslogik unterzubringen (die soll ja nichts über das Eingabefeld wissen). Das erfordert aber im Businessobjekt auch die Möglichkeit, eine detaillierte Fehlerreaktion einzuklinken. Die meisten Datenbindungs-Implementationen haben aber gerade in diesem Bereich noch erhebliche Lücken.