Blog by Jürgen Ebner

Model-View-ViewModel (MVVM)

Das Post soll eine Einführung in das Model-View-ViewModel (MVVM) bieten. Es soll einem erleichtern, den Wert des Patterns zu verstehen. Das Model ist einfacher als es die Meisten hinstellen.

Warum sollte man das MVVM verwenden?

Es gibt zahlreiche Vorteil für Entwickler von Silverlight und WPF Entwickler. Fragen die man sich vorher stellen sollte:

  • Muss man das Projekt mit einem Designer teilen und wie flexible sollte man beim Design und dem Code-behind sein?
  • Benötigt man Unit-Tests für die Applikation
  • Sollte man Komponenten für andere Projekte weiterverwenden können?
  • Wie flexible soll das User Interface austauschen können und die Logik dahinter als Code Basis für andere Projekte verwenden können.

Sobald man eine der Fragen, mit “ja” beantworten kann, dann ist das MVVM das richtige Model für das Projekt.

Überblick über MVVM

Die Blöcke des Patterns sind:

  • Das Model
  • Die View
  • das ViewModel (Kontolle und Präsentation)

Diese Blöcke sind der Schlüssel für die ganze Applikation (Daten und Informationen).

Das Model

Das Model kann man auch als Arbeitsgebiet bezeichnen. Das Model enthält die aktuellen Daten oder Informationen mit denen man im Projekt arbeitet. Beispiel des Models sind zum Beispiel Kontaktdaten (Name, Telefonnummer, Adresse, …) oder die Charakteristika eines Streams.

Das Model enthält nur die Daten und keine weiteren Services, die die Daten/Informationen weiterbehandeln. Die Businesslogik wird typischerweise von Model getrennt gehalten. Ausnahme ist z.B. wenn das Model eine Validation enthält.

Jedoch das Model wird meisten “rein” gehalten, was so viel heißt, wie eine Interpretation der “realen Welt”. Beispiel: ein Kontakt enthält ein Änderungsdatum und die Identität des Bearbeiters sowie einen Unique-Identifier (Datenbank Informationen). Das Änderungsdatum hat keine Bedeutung für einen Kontakt in der “wirklichen Welt”, ist aber ein Funktion, wie ein Model verwendet wird, beobachtet und im System verharrt.

Beispiel:

public class ContactModel : INotifyPropertyChanged
{
private string _firstName;
public string FirstName
{
get { return _firstName; }
set
{
_firstName = value;
RaisePropertyChanged("FirstName");
RaisePropertyChanged("FullName");
}
}
private string _lastName;
public string LastName
{
get { return _lastName; }
set
{
_lastName = value;
RaisePropertyChanged("LastName");
RaisePropertyChanged("FullName");
}
}
public string FullName
{
get { return string.Format("{0} {1}", FirstName, LastName); }
}
private string _phoneNumber;
public string PhoneNumber
{
get { return _phoneNumber; }
set
{
_phoneNumber = value;
RaisePropertyChanged("PhoneNumber");
}

}
protected void RaisePropertyChanged(string propertyName)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler != null)
{
handler(this, new PropertyChangedEventArgs(propertyName));
}
}
public event PropertyChangedEventHandler PropertyChanged;
public override bool Equals(object obj)
{
return obj is ContactModel && ((ContactModel) obj).FullName.Equals(FullName);
}
public override int GetHashCode()
{
return FullName.GetHashCode();
}
}

Die View

Die View: ist das was man wirklich sieht, mit dem der User interagieren kann. Es ist die Präsentation der Daten. Es werden die Daten in einer für den Anwender besseren Ansicht dargestellt (zB Datum in verständlicher Form und nicht als Sekunden, die seit 1.1. 1970 vergangen sind). Die View verwaltet den Input (Tastendruck, Mausbewegungen, …) welche schließlich die Eigenschaften des Models beeinflussen.

Das MVVM hat eine aktive View. Im Gegensatz zu einer passiven View,  wo die View keine Ahnung vom Model haben und die Manipulation durch den Controller/Presenter erfolgt. Die View im MVVM enthält Verhalten, Events und Data-Bindings, welche automatisch voraussetzen, dass man das darunterliegende Model und ViewModel kennen muss.  Während diese Events und Behaviors können zu Eigenschaften, Methodenaufrufen und Commands gemappt sein, ist die View nur für die Abarbeitung der eigenen Events zuständig und übergibt es nicht vollständig dem ViewModel.

Die View ist nicht für die Aktualisierung Ihres Status verantwortlich, das muss das ViewModel machen. Die View zeigt sich hauptsächlich im XAML-Code.

ViewModel (Kontroller/Präsentator)

Das ViewModel ist ein Schlüsselstück des Dreiecks weil es das Bindungsglied zwischen der View und dem Model ist und die Separation der Präsentation und der Logik überhaupt erst ermöglicht. Das Model enthält einfach nur die Daten und die View enthält die formatierte Daten und der Kontroller dient als Verbindung zwischen beiden. Der Kontroller erhält den Input von der View und platziert es zum Model oder interagiert mit einem Service um ein Model zu erhalten und übersetzt die Eigenschaften und übergibt es an die View.

mvvm

Das ViewModel enthält genauso Methoden, Commands und andere Punkte, die helfen einen Status der View aktuell zu halten, bearbeitet das Model als Ergebnis der Aktion der View und löst Events in der View selbst aus.

Martin Fowler beschreibt im Post Presentation Model eine Implementation ein Präsentations Model, welches speziell für WPF (und später auch für Silverlight) designed wurde.

Das Beispiel  des Muster zeigt oft einen Focus auf XAML für die View-Definition und Data-Binding für Commands und Eigenschaften. Data-Binding ist mehr ein Implementationsdetail des Muster als eine Eigenheit des Patterns selbst.

Die View und das ViewModel

  • die View und das ViewModel kommuniziert über Databinding, Methodenaufruf, Properties, Events und Nachrichten.
  • das ViewModel bringt nicht nur Models miteinander in Kontakt, sondern auch andere Eigenschaften (wie State-Information) und Commands
  • die View behandelt die eigenen UI-Events und mapped sie dann mit dem ViewModels via Commands
  • Das Model und die Eigenschaften des ViewModel werden von der view via 2-Weg-Databinding aktualisiert.

2 Mechanismen spielen oft eine Rolle bei der Implementations des Pattern, das sind Triggers (insbesondere Datentriggers) in WPF und Visual State Manager (VSM) in Silverlight. Diese Mechanismen helfen dabei das Muster durch UI-Behaviors an das darunterliegende Model zu implementieren. Bei Silverlight Applikationen sollte das VSM die erste Wahl sein, um Transitionen und Animationen zu koordinieren. Mehr dazu im Post von Justin Angel: Learn more about VSM.

Das ViewModel und das Model

Das ViewModel ist gänzlich für das Model in diesem Muster verantwortlich und nicht nur für:

  • das ViewModel kontaktiert das Model oder Eigenschaften, die in Beziehung zum Model stehen, direkt wegen dem Databinding
  • Das ViewModel kann ein Interface zu einem Service, Configurationsdaten, … enthalten, mit der Anweisung um Properties anzufordern oder zu manipulieren, welche zur View gehören.

Basis MVVM Framework

Ein Basis MVVM Framework sollte 2 Dinge enthalten:

  1. Eine Klasse, welche entweder ein DependencyObject ist oder ein INotifyPropertyChanged implementiert, um das Databinding vollständig zu unterstützen.
  2. etwas das eine Art Commanding unterstützt.

Seit Silverlight 3 wird der 2. Punkt, durch das ICommand Interface zur Verfügung gestellt, aber ist noch nicht implementiert. In Silverlight 4 ist Commanding mehr “out of the box”. Commands erleichtern das Binding von Events von der View zum ViewModel. Diese Details erleichtern einem das verwenden des MVVM-Pattern.

In Blend und dem freien Blend SDK gibt es zahlreiche Unterstützung für Binding und Behaviors. Man kann auch das Video von Jeremy Likness,  MVVM with MEF in Silverlight, anschauen, um einen Überblick zu bekommen, wie einfach es ist das MVVM-Pattern, auch ohne bestehendes Framework,  zu implementieren

6 people like this post.

2 Antworten auf Model-View-ViewModel (MVVM)

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

A1 Brand

Contact us

Copyright © 2011. All Rights Reserved.