MVC oder MVVM?

Wer mit Silverlight oder WPF Applikationen programmiert, hat vielleicht schon von diesen verwirrenden Abkürzungen gehört. Besonders MVVM wird als neues Paradigma für Silverlight/WPF empfohlen. Bei allen Ansätzen geht es zunächst darum, die Ansicht/UI, die Logik dahinter und die Daten zu trennen. Der Sinn einer Trennung von UI und Daten leuchtet unmittelbar ein, denn Daten können auf unterschiedliche Weise in einer Ansicht visualisiert werden. So lassen sich Dateien eines Verzeichnisses etwa als Liste von Dateinamen oder als Liste von Thumbnails darstellen.

Die UI besteht aus zwei Teilen:

1. Die eigentliche Visualisierung mit Widgets der jeweiligen Plattform (in Silverlight wird dies in XAML realisiert).

2. Die Logik der Bedienungsoberfläche, also wie sich die Oberfläche bei Benutzereingaben verhalten soll.

Der Vorteil bei einer Trennung ist u.a. eine gute Wiederverwendbarkeit der beiden Teile UI-Logik und Daten. Besonders, wenn man Komponenten oder Anwendungen sowohl in Silverlight und als auch WPF realisieren möchte, kann man davon profitieren.

Die oben genannten Strategien versuchen diese Dreiteilung zu realisieren.

MVC - Model View Controller

Z.B. für ASP.Net Webseiten gibt es das MVC Framework (mittlerweise in der Version 2.0). Hierbei registriert sich der View beim Model für Änderungen und stellt die Daten des Modells direkt dar. Der Controller nimmt Benutzereingaben entgegen und leitet diese an das Modell weiter. Außerdem kann er den View einschränken (etwa UI-Elemente deaktivieren) bzw. verändern (z.B. Animationen anstoßen).

MVVM - Model View ViewModell

Hierbei kennen sich Model und View nicht gegenseitig. Dazwischen vermittelt vielmehr das sogenannte ViewModel, das sich seinerseits als Beobachter beim Modell registriert. Der View wiederum bekommt sein zugehöriges ViewModel zugewiesen. D.h. der View kennt das ViewModel, aber das ViewModel kennt die Views (potentiell also Mehrzahl) nicht, die das ViewModel verwenden. Dadurch wird eine sehr gute Trennung der Komponenten erreicht. Das ViewModel implementiert die "Logik" der UI und kann auch mittels Unit-Tests isoliert getestet werden. Der View ist dann nur noch für die Anzeige (das Rendern) und das Weitergeben der Benutzereingaben an das ViewModel zuständig. 

In Bezug auf WPF und Silverlight kann das gleiche ViewModel verwendet werden und nur der View muss angepasst werden. Die Kommunikation zwischen View und ViewModel geschieht in WPF/Silverlight normalerweise über Commands und DataBinding (das ViewModel implementiert INotifyPropertyChanged und stellt Commands (implementieren ICommand) zur Verfügung).

Wer mehr über das MVVM Konzept und die Anwendung in WPF und Silverlight erfahren möchte, findet hier eine gute Einführung.