Livebindings Pro Contra

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

[Sir Rufo]

Also mE muss die GUI so dumm wie möglich sein, also sollte im Idealfall nur die reinen Controls beinhalten.

Das Binding ist dafür da, die Daten zwischen dem Control und dem Objekt auszutauschen und auch die Validierung vorzunehmen.
DSharp bietet da entsprechende ValidationRules.

Andernfalls wäre es ja nicht möglich, die GUI einfach so mal auszutauschen oder auch Tests unabhängig von der GUI auszuführen.

Zitat von 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?

Mit DSharp kann man alle Properties eines Controls beeinflussen

Und für diese Fehler-Anzeige liefert DSharp auch ein schönes Beispiel mit

[bernau]

Die Trennung macht für mich nur dann sinn, wenn auch die Fehlerüberprüfung in die Logik mit hineinkommen würden, sodaß man wirklich keinen Code mehr im Formular benötigt. Dazu müssten schon neutrale Properties wie z.B. "Eingabefehler" in den verschiedenen Controls (am besten in TControl) vorhanden sein. Ein TEdit würde dann automatisch die Farbe ändern können, Buttons automatisch disabled etc. Ansonsten habe ich die Logik in zwei verschiedne Bereiche verteilt und das ist unübersichtlich.

[mquadrat]

Nehmen wir als Beispiel mal das blinken lassen. Das gehört zur GUI. Im ViewModel (falls man MVVM nutzt) würde nur eine Eigenschaft entsprechend gesetzt (z.B. Fehler). Wie eine Änderung der Eigenschaft "Fehler" visualisiert werden muss, muss man natürlich in der GUI festlegen und nicht in der Geschäftslogik. Dann hätte ich ja doch wieder gekoppelt. Dazu kommt, dass GUI A blinken kann, GUI B aber nicht.

Ist ein bisschen wirr geschrieben, aber ich denk man erkennt grob was ich eigentlich sagen wollte

@Trennung

Das Ziel der Trennung ist NICHT, dass im Form kein Code mehr stehen darf. Es darf nur kein funktionsrelevanter Code stehen.

[Sir Rufo]

Streng genommen besteht die GUI (bzw. die View) auch aus Code. Nur weil fast alle die VCL benutzen und wir keinen Code sehen ist er ja trotzdem da

Was die View zur Verfügung stellen soll (Edit-Felder, Combo-Boxen, Fehler-Indikatoren) und deren Namens-Konvention ist ja eine Absprache zwischen dem View-Entwickler und dem Model-Entwickler und kann somit als Schnittstelle gelten.

Das Bindung ist dann dafür da, diese Schnittstelle zu bedienen.

Wie die View das dann auf den Bildschirm bekommt bleibt der View dann überlassen.
Ob das blinkt, oder ein Bild angezeigt wird, oder der gesamte Bildschirm flackert ... egal.
Über das Binding gibt es eine entsprechende Rückmeldung (z.B. ein Boolean-Flag und den Fehler-Text) und die View kann das dann anzeigen wo sie möchte.

[webcss]

Zitat von Sir Rufo:

Was die View zur Verfügung stellen soll (Edit-Felder, Combo-Boxen, Fehler-Indikatoren) und deren Namens-Konvention ist ja eine Absprache zwischen dem View-Entwickler und dem Model-Entwickler und kann somit als Schnittstelle gelten.
...
Wie die View das dann auf den Bildschirm bekommt bleibt der View dann überlassen.
Ob das blinkt, oder ein Bild angezeigt wird, oder der gesamte Bildschirm flackert ... egal.
Über das Binding gibt es eine entsprechende Rückmeldung (z.B. ein Boolean-Flag und den Fehler-Text) und die View kann das dann anzeigen wo sie möchte.

+1 vollkommen richtig!

[Uwe Raabe]

Zitat von Sir Rufo:

Also mE muss die GUI so dumm wie möglich sein, also sollte im Idealfall nur die reinen Controls beinhalten.

Da bin ich halt anderer Meinung. Vielleicht ist das aber auch nur eine Frage unterschiedlicher Terminologie zwischen uns.

Zitat von Sir Rufo:

Das Binding ist dafür da, die Daten zwischen dem Control und dem Objekt auszutauschen und auch die Validierung vorzunehmen.

Da stimme ich mit dir überein.

Zitat von Sir Rufo:

DSharp bietet da entsprechende ValidationRules.

Ich hatte eh vor, mich bei nächster Gelegenheit etwas intensiver mit DSharp zu beschäftigen. Vielleicht habe ich ja bei der groben Übersicht noch das eine oder andere Feature übersehen.

Zitat von Sir Rufo:

Andernfalls wäre es ja nicht möglich, die GUI einfach so mal auszutauschen oder auch Tests unabhängig von der GUI auszuführen.

Nach meiner Erfahrung ist es eben gar nicht so einfach, eine GUI einfach so auszutauschen, wenn sie eben nicht einfach nur "dumm" ist. Dabei meine ich jetzt nicht die Validierung der Eingaben, die (falls nicht schon im Control selbst durchgeführt) sicher in die Geschäftslogik gehört, sondern die Vermittlung etwaiger Eingabefehler an den Benutzer. Es reicht mir eben nicht, bei einer Fehleingabe lediglich ein Fenster mit einer Fehlermeldung aufpoppen zu lassen, sondern ich will dem Benutzer auch die Korrektur dieses Fehlers so einfach wie möglich machen. Dazu muss ich deutlich mehr über die Art des Fehlers wissen, als bloß die Tatsache, daß einer aufgetreten ist.

GUI-Design ist eben doch etwas mehr, als nur Formular-Design. Wenn es also etwas mehr sein darf, als nur das stumpfe Ausfüllen von Formularfeldern, gehört dazu auch die dynamische Interaktion mit dem Benutzer. Diese wiederum ist so stark von den Controls auf dem Formular und ihrer Bedeutung abhängig, daß sie sicher nicht in die Businesslogik gehört. Natürlich kann man auch hier versuchen, den UI-Code von den Controls zu trennen, aber das führt in den meisten Fällen zu mehr Problemen als man damit löst. Dafür sind die verschiedenen GUI-Frameworks (VCL, FMX, Web usw.) doch zu unterschiedlich.

Ich stimme dir auch in Bezug auf die GUI-unabhängigen Tests zu, was aber sofort die Frage nach den verbleibenden GUI-Tests aufwirft (man nehme z.B. nur mal die TAB-Reihenfolge). Diese sollten konsequenterweise dann aber auch ohne reale Businessobjekte durchführbar sein. Das wäre dann wiederum die Domäne der Mocks (gibt's aber wohl auch in DSharp).

[Sir Rufo]

@Uwe

Wenn die View (GUI) sich einfach nur auf das Anzeigen konzentriert, dann kann ich diese View beliebig gegen eine andere austauschen, wenn diese sich an die Schnittstellen-Konventionen (Model<->View) hält.

Bei DSharp ist z.B. folgendes möglich:

Delphi-Quellcode:

TBinding.Create( Contact, 'Vorname', View, 'LabelVorname.Caption' );
TBinding.Create( Contact, 'Vorname', View, 'LabelVorname.Text' );

Wenn in der View ein Object (z.B. ein TControl) mit dem Namen "LabelVorname" gefunden wird und selbiges eine Eigenschaft "Caption" oder "Text" hat, dann wird der Wert von "Vorname" dorthin geschrieben.
So würde man z.B. die geänderte Namens-Konvention zwischen FMX, VCL und IntraWeb lösen.

Und die View darf ruhig dumm sein (sie darf sehr geschickt sein, die Daten zu präsentieren oder entgegenzunehmen) in Bezug auf Validierung oder Speicherung.
Auch ob das Edit-Feld x zum Zeitpunkt y aktiv oder inaktiv sein soll ist nicht Aufgabe der View, dieses alles steuert man über das Binding.

Und dann ist man durchaus in der Lage die View einfach so auszutauschen.

So würde ich die Abhängigkeiten sehen:

Code:

View <-> Binding ( = View-Logik) <-> ( Model-Logik <-> ) Model

[neo4a]

Es ist noch gar nicht soo lange her, da wurde gefordert, dass die gesamte Business-Logik in die Datenbank gehört (über Trigger, StoredProc). Arbeitete man nur mit DB-aware Controls, brauchte es auch keine Bindings.

Es kommt für mich gar nicht überraschend, dass (Live)Bindings erst jetzt bei Delphi ankommen, weil vor allem die spezielle Konstruktion der VgScene/FMX-Controls eine statische DB-Awarness unsinnig machen (VgScene als Vorläufer der FMX kennt auch deshalb schon Bindings). Zuvor war der Delphi-RAD-Ansatz mit VCL-DB-Controls völlig ausreichend und wir alle haben damit ja auch großartige Apps geschrieben. Und so hätte es auch bleiben können.

Will man aber nun mehrere Plattformen unterstützen oder einfach nur die schicken FMX-Controls nutzen und/oder testbaren Code schreiben und mit Mockups testen, dann kommt man mit den Alt-Ansatz allerdings nicht mehr so weit.

Mit DSharp-Bindings kann man sich sein Entwicklerleben schon erleichtern. Mit DI-Containern wie Spring4Delphi kann man herrlich modularisieren. Und wenn man (wie N.Hodge es fordert) nur noch gegen Interfaces programmiert und die Klassen-Definitionen nur noch im Implementation-Teil der Unit unterbringt, ist man schon ganz modern dabei.

Das alles ist nur noch zu toppen, durch ein MVVM-Ansatz. Die seit heute in DSharp verfügbaren Demos lassen einen schon ahnen, wohin die Reise geht. Da ist - dank Konventions-Logik - kaum noch Code in den Views und selbst in den nichtvisuellen Komponenten passiert nichts mehr. Allein durch die Benennung wird alles automatisch zusammen "geklickt". Ziemlich cool.

[Stevie]

Ich gebe Uwe recht, wenn es darum geht, dass bestimmte GUI Controls miteinander interagieren ("wähl ich hier X aus, wird dort Y eingeblendet"). Das wird im klassischen Ansatz oft alles auf ein Frame oder Form gepackt und lustig irgendwelche Sachen visible oder non visible gemacht. Oftmals werden aber auch - im Visual Studio user controls genannt - in Delphi würde ich Frames preferieren, benutzt. Generell bin ich aber der Meinung, dass nahezu jede Businesslogik ohne Oberfläche funktionieren muss.

Also angenommen, ich möchte aus verschiedene Zahlungsmethoden auswählen. Wähl ich Kreditkarte aus, werden die Controls für die relevanten Kreditkarten Infos eingeblendet (zusammen auf einem Usercontrol bzw Frame, im MVVM Jargon also z.b. KreditkartenView, evtl auch unterschiedliche je nach Kreditkarte), wähl ich Überweisung aus, muss ich ganz andere Daten ausfüllen, in dem Fall wird das ÜberweisungView angezeigt. Auch hier wieder, modulare Testbarkeit und Erweiterbarkeit. Hab ich irgendwo eine andere Stelle, wo ich Kreditkarten Infos anzeigen oder Editieren muss, zack, die View rein, fertig.

Bezüglich der Rückmeldung der UI auf eventuelle Validierungen, Pflichtfelder, sonstwas. Da kommt es in der Tat sehr stark darauf an, um was es sich handelt. Wenn generell ein Fehler auftrat, sagt das ViewModel (die Business Logik) einfach nur, dass und eventuell welcher Fehler auftrat. Und auf diese Fehler Information kann man sehr wohl die View wieder Binden. Wer sich DSharp anschaut, es gibt ein kleines Beispiel zu den Validierungen, wo ein kleines Icon eingeblendet wird, sobald ich einen nicht zulässigen Wert eingebe. Denkbar wäre auch eine Listbox oder ein Memo an die Liste der ValidationErrors zu hängen und dann seh ich, was alles fehlgeschlagen ist.

Der MVVM Ansatz von DSharp ist bei weitem noch nicht ausgereizt - wie schon im Blog vor einiger Zeit erwähnt, ich schau sehr stark bei Caliburn.Micro ab, weil ich das enorm gut finde - es gibt auch noch schwergewichtigere MVVM Frameworks (Prism z.B. - was übrigens nur den Namen mit der gleichnamigen Object Pascal Sprache für .Net von RemObjects gemeinsam hat). Aber ich hab ja auch gerade erst angefangen und viele Sachen werden auch erst klar, wenn man anfängt, damit eine Anwendung zu bauen.

Am Anfang erfordert diese ganze Denkweise etwas Einarbeitung, aber jeder, der auch durch .Net (speziell WPF) damit in Verbindung war, ist eigentlich begeistert. Großer Vorteil dort ist halt (noch), dass man dort durch das XAML sehr viel relativ elegant lösen kann, vor allem dadurch, dass viele Dinge, die man derzeit in Delphi nur string basiert machen kann (und demnach erst zur Laufzeit auftreten), dort zur design bzw compile time Fehler werfen.