So What Exactly is a View-Model

Interessanter Artikel auf InfoQ zum Thema MVVM:  „So What Exactly is a View-Model“.

Es werden verschiedene Techniken vorgestellt, wie View-Models implementiert werden können. Das hat natürlich nur Relevanz für Desktop-Anwendungen, d.h heutzutage praktisch nur für WPF und Silverlight. Vielleicht auch mal für HTML5, wenn es groß und stark ist…

In Webanwendungen à la MVC kann man durchaus auch View-Models einsetzen, aber die haben da eine ganz andere Struktur und die muss man jetzt hier ausblenden.

Das solche Artikel wichtig sind, zeigt mir das „offizielle MVVM-Tutorial von Microsoft“, ellenlang, aber inhaltsleer, weil es ein so primitiv einfaches Beispiel verwendet, dass es für die Praxis einfach irrelevant ist. Sinnvolle Anwendungen aus der Praxis haben komplexe Bäume, dynamische Ansichten und andere Verwickeltheiten die solche Blueprints ad absurdum führen.

Na gut, zurück zur konstruktiven Seite des Artikels. Man kann ja durchaus MVVM benutzen und wirklich etwas zur Lesbarkeit des Codes beitragen.

Mein Favorit ist folgende Kombination (wird im InfoQ-Artikel als eine Variante erläutert):

  • View-Model per Page
  • NotifyPropertyChanged in Model implementieren

View-Model per Page:

Ein View-Model wird je View(-Klasse) definiert, somit es kann durchaus mehrere View-Models für eine Enitity geben, z.B. ein DetailViewModel und ein ListViewModel, wobei auch gemeinsame Basisklassen oder gemeinsame Komponenten denkbar sind, um Duplizierung gemeinsamer Logik zu entfernen.

Selbst Command-Bindings  (die ich nicht befürworte!),  sind damit sauber umsetzbar.

 INotifyPropertyChanged in Model implementieren

Es stellt sich immer die Frage, wie man die geänderten Eigenschaften und Collections handhabt. Wenn man mehrere View-Models hat und à la Microsoft BluePrint INotififyPropertyChanged ausschließlich im View-Model handhabt, nutzt man die Möglichkeiten der selbst-aktualisierenden GUI überhaupt nicht aus.

Das View-Model sollte nicht Property-Changed aufrufen, sondern sich stattdessen bei der Entity auf Änderungen registrieren und diese Änderungen im eigenen Property-Changed Event nur wiederholen. Somit aktualisieren sich beliebig viele View-Models bei Änderungen an einem einzigen Geschäftsobjekt.

Bei Collections ist das Synchronisieren der Änderungen etwas aufwändiger, aber dafür kann man sich spezielle Klassen schreiben, die das für einen machen.

Und wozu braucht man ein View-Model überhaupt?

In diesem Artikel ging es um Best Practices für View-Models. Der Vollständigkeit halber aber noch mal meine Meinung dazu, warum man es überhaupt braucht:

Der eine oder andere meint View-Models sind „sauberer“. Ich kann diesen Quatsch nicht hören, was hat das schon für einen Wert? View-Models haben einen ganz praktischen Wert: man möge doch mal versuchen ohne View-Models eine ansprechende Oberfläche in WPF zu implementieren. IF value < 0 THEN color = RED. Das geht da halt nicht. Stattdessen gibt es 3 Möglichkeiten: Trigger, ValueConverter und eben das gebundene Objekt. Wenn das gebundene Objekt eine Entity wäre, könnte man da einfach gesagt nicht einfach alles reintun, was man in 122 Views braucht, und nur mit Triggern und ValueConvertern sind sinnvolle Ansichten nur sehr umständlich umsetzbar. Dann doch lieber ein View-Model dazwischenschalten!

Lustig finde ich übrigens:  Eigentlich ist MVVM blöd benannt, denn im Namen steht ja Model neben View. Sollte vielleicht besser MVMV heißen, klingt aber nicht so gut…