Livebindings Pro Contra

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

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

Zitat von bernau (Beitrag 1136807)

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 :D

@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:

Zitat von Sir Rufo (Beitrag 1136853)

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 :thumb: vollkommen richtig!

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1136841)

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:

Zitat von Sir Rufo (Beitrag 1136841)

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:

Zitat von Sir Rufo (Beitrag 1136841)

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:

Zitat von Sir Rufo (Beitrag 1136841)

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