(MVC) Model-View-Controller – reloaded as (MVVM) Model-View-ViewModel

In der 50. Ausgabe (10.07) des Magazins “dot.net” informieren uns Thomas Huber (Entwickler und Trainer bei Trivadis) und Christoph Pletz (Consultant und Trainer bei Trivadis) über das Model-View-ViewModel Pattern (MVVM) als Variante des Model-View-Controller Patterns (MVC). Der Early Bird der WPF Entstehung wird das noch aus den Avalon Zeiten kennen. In seinem Blog Tales from the Smart Client began John Gossman im Oktober 2005 unregelmäßig über diese Variante des alten Smalltalk Patterns zu schreiben. Die jeweiligen Artikel sind wirklich empfehlenswert, doch mir persönlich fehlen da ein paar Überlegungen und Seitenblicke, die ich nicht unerwähnt lassen will.

Model View Controller

Das berühmte Pattern aus den Anfängen der objektorientierten Entwicklung ist weitläufig verbreitet und unterscheidet sich in der Interpretation nur hinsichtlich der Pfeilrichtungen. Während manche Vertreter des Patterns der Meinung sind, dass ein Controller kein Wissen über die Darstellung der Daten haben muss, sehen das die pragmatischen Entwickler und Architekten etwas anders. Bei der zweiten Sicht des Patterns wird die Trennung zwischen Sicht und Controller immer stärker aufgelöst und eine direkte (unkontrollierte) Darstellung der Daten- und ihrer Ereignisse findet kaum statt. Diese zweite Sicht entwickelte sich im Laufe der pragmatischen Entwicklung und auf der Basis von anderen Programmiersprachen denn C++ und Smalltalk, die im Endeffekt auch etwas mehr Durchsetzungsvermögen besaßen.

Gehen wir in der IT-Geschichte ein paar Jahre weiter in die Ende der 1990er so finden wir bei den meisten Programmiersprachen, Frameworks ein Pattern, das Controller und View stark verbindet. Dies ist bei Java Swing, bei Windows Forms und den meisten GUI Frameworks der Fall, die sich dem Pragmatismus unterwarfen, dass dargestellte Daten beispielsweise zur Anzeige formatiert werden müssen und deren Formatierung auch bei der Dateneingabe zu validieren sei. Wenn also das Wissen über die korrekte Form der Daten auch in der Anzeige vorhanden sein muss, dann könnte man es ja auch verwenden. Daten, deren Kontrolle und der Ablauf einer Anwendung unterliegen zudem auch den Möglichkeiten diese anzuzeigen. Auf einem Mobiltelefon muss eine etwas andere Anwendung als auf einem 21“ Monitor kontrolliert werden, die jedoch die gleichen Daten bearbeitet.

Model-View-ViewModell

Mit dem Aufkommen von Definitionssprachen (unglückliche Bezeichnung, aber mir fällt keine bessere ein) wie XUL und XAML beginnt sich das klassische Pattern erneut zu bewegen. Statt dem Controller haben wir ein „ViewModell“ stehen, das Kenntnisse über die Oberfläche besitzt. Das ViewModel kann steuernd eingreifen und die Daten entsprechend weiterreichen. Durch Databinding entsteht zwischen View und ViewModel eine enge Kopplung, die nicht zwingend an das Model als Datenhaltungsschicht weiter gegeben werden muss. Die Vorteile des MVVM gegenüber dem klassischen Weg des Code-Behind ergeben sich aus der Unit-Testbarkeit und des tatsächlichen Parallelisierens der Entwicklung.

In dem Dot.Net Magazin Artikel bringen Huber und Pletz eine einfache Anwendung als Beispiel ein, die über INotifyPropertyChange und INotifyCollectionChange zur View ihre Schnittstellen definiert; und zum Datenmodell über eigens definierte Schnittstellen die Datenheranzieht. Die Einzelheiten der Beispielanwendung will ich hier nicht erläutern, dazu lese man bitte den entsprechenden Artikel. Es werden noch CommandBinding, DataTriggers erläutert und ein paar Events abgefeuert, so dass sich insgesamt ein rundes Bild ergibt. Am Ende des Artikels stellen die Autoren die Frage nach der…

Kommerziellen praktischen Anwendbarkeit von MVVM

Diese Frage kann ich durchaus beantworten. Das MVVM lässt sich auf den Workflow mit einer Designagentur wunderbar anwenden. In zwei in der Aufgabenstellung völlig unterschiedlichen Projekten wurde das Pattern die Basis für die kooperative Entwicklung.

In dem ersten Projektauftrag sollten eine Vielzahl von Masken dynamisch geladen und mit Daten verbunden werden, die partiell durch den Benutzer manipuliert werden konnten. Der Fall ist in meinen Augen recht einfach, daher kann ich auf ein Bild verzichten. Die Masken und Animationen wurden von reinen Designern erstellt und abgelegt. Ein Oberflächenprogrammierer der Designagentur (ein wahrer Flashexperte) arbeitete sich in die WPF-C# Welt ein und programmierte die Steuerung der Oberfläche, betreffend Ereignisse. Unsere Aufgabe als Softwarhaus war es, die Daten bereit und ein Framework zur Verfügung zu stellen, welches das MVVM Pattern abbildete. Jenes lädt dynamisch die Masken als View, verbindet sie mit dem ViewModel, das bei der Instanziierung mit den Daten verbunden wird.
Der zweite Projektauftrag ist etwas komplexer, somit benötige ich ein Bild ;-)

In diesem komplexen Szenario ergibt sich die tatsächliche Vierteilung der Schichten, die Gossman in seinem Blog im April 2006 als UML Diagramm festhält. In dem Projekt findet die Datenhaltung auf verteilten System statt. Die Daten werden aus lokalem Speicher (Datenbanken, XML-Files) und aus Webservices ermittelt. Lokale Webservices (Windows Communication Foundation) liefern diese als statuslose Services auf Anfrage an Komponenten weiter. Jene werden von Clients genutzt, welche die Oberflächensteuerung übernehmen. Verschiedene GUI Provider bestehend aus WPF Masken, HTML (Gadget) und WindowsForms (Tray) werden durch die Clients gesteuert und von den Komponenten mit Daten und Geschäftslogik bedient.

Der Workflow zwischen Entwicklung und der Designagentur erhielt die Schnittstelle in der Komponente.

Während das Softwarehaus die Verbindung zu dem Service, die Kommunikation und die Konfiguration übernahm und jene in bilateral vereinbarten Schnittstellen in für die GUI aufbereiteter Form zur Verfügung stellte, entwickelten die Programmierer der Designagentur den Clientbereich, welche sich lediglich auf die Steuerung der Oberfläche konzentrieren musste. Designer erarbeiteten mit Expression Blend die Oberflächen und lieferten diese an die Programmierer der Designagentur.

Fazit

Es zeigt sich, dass das MVVM Pattern durchaus Haltbarkeit bezüglich kommerzieller Anwendbarkeit besitzt. Doch in komplexeren Fällen wird man, um weiteren Nutzen zu gewinnen nicht umhin kommen eine weitere Trennungsschicht zu etablieren und sich immer weiter von der Idee des CodeBehind verabschieden. Die Spezialisierung im Designbereich hinsichtlich Flash hat schon länger zwischen Flash-Grafikern und Flash-Programmierern unterschieden. Diese Arbeitsteilung wird sich auf praktische Art und Weise auch im Bereich WPF als hilfreich erweisen. Eine Abbildung im Pattern der Software-Architektur ist nur folgerichtig.