Model-View-ViewModel (MVVM)

Beim Model-View-ViewModel (MVVM) ist eine Architektur um Software zu entwickelt. Hierbei gibt es eine klare Trennung zwischen Daten und Funktionalität hin zur Benutzeroberfläche. Zusammen mit MVVM empfiehlt es sich auch noch Test getriebene Entwicklung zu betreiben um so die maximale Qualität der Software zu sichern. Die hierbei entstehende Aufteilung soll uns die folgende Grafik näher erläutern.

Aufbaustruktur von MVVM.

Aufbaustruktur von MVVM.

Hierbei ist folgendes anzumerken: Allein das Model ist für die Verarbeitung von Daten, Zugriffe auf Datenbanken und Dateien sowie Funktionalität zuständig. Sämtliche Zugriffe egal ob Web oder Lokal, egal ob Datenbank oder Datei und egal ob Funktion oder Methode – all dies gehört ins Model und nirgends anders hin! Die nächste Schnittstelle wäre unser ViewModel. Dies bereitet die vom Model zur Verfügung gestellten Daten für die View auf und bildet die hierfür nötigen Eigenschaften an, an welcher sich die View schließlich binden kann. Auch sind hier die Aktionen der Buttons und sämtliche „Logik“ der Benutzeroberfläche abgelegt werden, wobei keine Funktionalität hier implementiert wird sondern lediglich Aufrufe beim Model erfolgen. Der dritte und letzte Teil bei MVVM ist die Benutzeroberfläche oder auch View. Hier wird die Anzeige getätigt, evtl. werden Daten die vom ViewModel stammen nochmal durch Converter geschickt (diese sollten aber nicht missbraucht werden!). Da hier die gesamte Benutzerinteraktion stattfindet, sollte diese Schnittstelle auch stehts einen anderen Thread als die Funktionen nutzen um bei lang andauernden Aktionen nicht zu freezen.

In der Grafik ist jedoch noch ein Teil abgebildet. Der orange dargestellte „Binder“-Teil. Dieser sorgt für die Bindung zwischen View und ViewModel und bekommt in der Regel kein eigenes Projekt. Hier werden die Events in einer Warteschlange gereiht und abgearbeitet. Dies gilt für beide Richtungen. Auch bekommt die View über Änderungen an Daten im ViewModel von hier aus bescheid. Somit dies die eigtl. nicht Sichtbare Schnittstelle zwischen Oberfläche und Funktionalität.

Warum sollte MVVM verwendet werden? Und warum nicht? Hier eine Reihe an positiven und negativen Eigenschaften:

Pro:
– Klare Strukturierung des Sourcecodes
– Definierte Trennung der Komponenten, wodurch diese auch frei wechselbar sind
– Einfache Wartbarkeit

Kontra:
– Aufwändiger als direkte Entwicklung
– Sehr gering höherer Performance Aufwand

Ob die positiven Eigenschaften den negativen überlegen sind, muss jeder für sich entscheiden. Ich für meinen Teil werde – solange noch keine „bessere“ Technologie soweit ist, mit MVVM Arbeiten da es doch einige Vorteile liefert welche ich gerne nutze. Was auch noch anzumerken ist, so sollte das ViewModel keine View-Assemblys wie „PresentationCore“, „WindowsBase“, usw. Referenzen – selbiges gilt auch für das Model. Für genau diese Teile sind die Converter – aber nicht dafür um aus System.String ein System.Int32 zu machen usw. den dies hat im ViewModel zu geschehen!

Alle die eine detalliertere Beschreibung benötigen, können dies hier finden: http://msdn.microsoft.com/de-de/magazine/dd419663.aspx 

Auch werde ich im laufe der nächsten Tage ein kleines MVVM-Framework in den nächsten Blogs Entwickeln um so auch dies noch besser zu erläutern.

 

Bekannte nutzbare MVVM-Frameworks: