Model View ViewModel

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche
QS-Informatik

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+)

MVVM-Konzept: Die Datenbindung (Data Binding) ermöglicht eine Trennung von Markup und Logik für die Darstellung (Presentation).

Model View ViewModel (MVVM) ist eine Variante des Model View Controller-Musters (MVC) zur Trennung von Darstellung und Logik der Benutzerschnittstelle (UI). Es zielt auf moderne UI-Plattformen wie Windows Presentation Foundation (WPF), Silverlight und HTML5 ab. MVVM sieht eine Rollentrennung von UI-Designern und Entwicklern vor, wodurch Anwendungsschichten von verschiedenen Arbeitsgruppen entwickelt werden können. Designer können einen Fokus auf User Experience setzen und Entwickler die UI- und Geschäftslogik schreiben.

Geschichte[Bearbeiten]

Das MVVM wurde 2005 von Microsoft MVP John Gossman veröffentlicht. Es ist eine Spezialisierung des Presentation Model von Martin Fowler[1] und ist mit diesem insofern identisch, als beide Muster Zustand und Verhalten der View in ein separates UI-Model (Presentation bzw. View Model) verschieben. Das Presentation Model ermöglicht allerdings das Erzeugen einer View unabhängig von der UI-Plattform, wohingegen das MVVM ursprünglich auf UIs mittels WPF abzielt. Es findet allerdings inzwischen auch in anderen Bereichen Anwendung, ähnlich wie bei MVC.

Beschreibung[Bearbeiten]

Das MVVM nutzt die funktionale Trennung des MVC und Datenbindung, um eine lose Kopplung zu erreichen. Es beinhaltet drei Komponenten, wobei Model und View denen des klassischen MVC ähneln:

  • Model: Datenzugriffsschicht für die Inhalte, die dem Benutzer angezeigt und von ihm manipuliert werden. Dazu benachrichtigt es über Datenänderungen und führt eine Validierung der vom Benutzer übergebenen Daten durch. Es beinhaltet die gesamte Geschäftslogik und ist für sich alleine durch Unit Tests überprüfbar.
  • View: Alle durch die Grafische Benutzeroberfläche (GUI) angezeigten Elemente. Es bindet sich an Eigenschaften des ViewModel, um Inhalte darzustellen und zu manipulieren sowie Benutzereingaben weiterzuleiten. Durch die Datenbindung ist die View einfach austauschbar und ihr Code-Behind gering.
  • ViewModel: beinhaltet die UI-Logik (Model der View) und dient als Bindeglied zwischen View und obigem Model. Einerseits tauscht es Information mit dem Model aus, ruft also Methoden oder Dienste auf. Andererseits stellt es der View öffentliche Eigenschaften und Befehle zur Verfügung. Diese werden von der View an Steuerelemente gebunden, um Inhalte auszugeben bzw. UI-Ereignisse weiterzuleiten. Insgesamt wird CRUD ermöglicht. Das ViewModel darf dabei keinerlei Kenntnis der View besitzen.

.NET[Bearbeiten]

In Bezug auf WPF und Silverlight bedeutet MVVM, dass die View aus rein deklarativem XAML-Markup besteht. Sie kann von UI-Designern etwa mittels Expression Blend entworfen werden, wobei lediglich Datenbindungen zum ViewModel erzeugt werden müssen, aber kein Code-Behind. Die Logik wird in einer Programmiersprache wie C# oder VB.NET implementiert. Die Abhängigkeiten zwischen Markup und Code werden minimiert.

Vor- und Nachteile[Bearbeiten]

Dieser Artikel oder nachfolgende Abschnitt ist nicht hinreichend mit Belegen (beispielsweise Einzelnachweisen) ausgestattet. Die fraglichen Angaben werden daher möglicherweise demnächst entfernt. Bitte hilf der Wikipedia, indem du die Angaben recherchierst und gute Belege einfügst. Näheres ist eventuell auf der Diskussionsseite oder in der Versionsgeschichte angegeben. Bitte entferne zuletzt diese Warnmarkierung.
Dieser Abschnitt ist eigentlich nur eigene Meinung. --160.45.45.61 18:00, 7. Mai 2013 (CEST)

Die Menge von Glue Code und Geschäftslogik im Code-Behind der View wird reduziert.[2] Dadurch können UI-Designer Views rein gestalten während Entwickler unabhängig davon die Models und ViewModels implementieren. Des Weiteren sind – die Korrektheit der Datenbindung vorausgesetzt – keine (in der Regel manuellen) UI-Tests nötig. Stattdessen genügen codebasierte Modultests des ViewModel. Zuletzt „erbt“ MVVM von MVC die leichtere Austauschbarkeit der View.

MVVM ist für Projekte mit einfachem GUI zu aufwändig. Für größere Anwendungen kann das Design eines ausreichend allgemeinen ViewModels im Voraus schwierig sein. Das Debugging der deklarativen Datenbindung ist ebenfalls schwieriger als bei imperativer Programmierung. Außerdem führt eine schlecht verwaltete Datenbindung zu einem erheblichen Speicherbedarf der Anwendung.

Siehe auch[Bearbeiten]

Einzelnachweise[Bearbeiten]

  1. Presentation Model
  2. John Gossman: Tales from the Smart Client: Advantages and disadvantages of M-V-VM.. Abgerufen am 28. Mai 2012.

Weblinks[Bearbeiten]