Einzelnen Beitrag anzeigen

Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.443 Beiträge
 
Delphi 12 Athens
 
#20

AW: Livebindings Pro Contra

  Alt 18. Nov 2011, 15:01
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.

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.

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.

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).
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat