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.