Was ist der Unterschied zwischen MVC und MVVM?

Question

Gibt es einen Unterschied zwischen dem Standardmuster "Model-View-Controller" und dem Model/View/ViewModel-Muster von Microsoft?

Answer 1

MVC/MVVM ist kein entweder/oder Wahl.

Die beiden Muster tauchen in unterschiedlicher Weise sowohl in der ASP.Net- als auch in der Silverlight/WPF-Entwicklung auf.

Für ASP.Net wird MVVM verwendet, um wechselseitige Bindung Daten innerhalb von Ansichten. Dies ist in der Regel eine clientseitige Implementierung (z. B. mit Knockout.js). MVC hingegen ist eine Methode zur Trennung von Anliegen auf der Server-Seite .

Für Silverlight und WPF ist das MVVM-Muster umfassender und kann erscheinen als Ersatz für MVC (oder andere Muster der Organisation von Software in getrennten Verantwortungsbereichen) zu fungieren. Eine Annahme, die häufig aus diesem Muster hervorging, war, dass die ViewModel einfach den Controller in MVC (als ob man das einfach ersetzen könnte durch VM para C in das Akronym und alles wäre vergeben)...

Das ViewModel macht no ersetzen nicht notwendigerweise den Bedarf an separaten Controllern.

Das Problem ist, dass ein View-Modell, um unabhängig testbar* und vor allem wiederverwendbar zu sein, wenn es gebraucht wird, keine Ahnung hat, welcher View es anzeigt, aber was noch wichtiger ist keine Ahnung, woher die Daten stammen .

*Hinweis: In der Praxis entfernen Controller den größten Teil der Logik, die Unit-Tests erfordert, aus dem ViewModel. Die VM wird dann zu einem stummen Container, der wenig, wenn überhaupt, Tests erfordert. Dies ist eine gute Sache, da die VM nur eine Brücke zwischen dem Designer und dem Programmierer ist und daher einfach gehalten werden sollte.

Selbst in MVVM enthalten Controller in der Regel die gesamte Verarbeitungslogik und entscheiden, welche Daten in welchen Ansichten unter Verwendung welcher Ansichtsmodelle angezeigt werden sollen.

Nach dem, was wir bisher gesehen haben, ist der Hauptvorteil des ViewModel-Patterns, Code aus dem XAML-Code-Behind zu entfernen um die XAML-Bearbeitung unabhängiger zu machen . Wir erstellen nach wie vor je nach Bedarf Controller, um die Gesamtlogik unserer Anwendungen zu steuern (kein Wortspiel beabsichtigt).

Die grundlegenden MVCVM-Leitlinien, die wir befolgen, sind:

• Ansichten eine bestimmte Form von Daten anzeigen . Sie haben keine Ahnung, woher die Daten stammen.
• AnsichtModelle eine bestimmte Form von Daten und Befehlen enthalten Sie wissen nicht, woher die Daten oder der Code kommen und wie sie angezeigt werden.
• Modelle die eigentlichen Daten enthalten (verschiedene Kontext-, Speicher- oder andere Methoden)
• Controller warten auf Ereignisse und veröffentlichen sie. Controller liefern die Logik, die steuert, welche Daten wo zu sehen sind. Controller stellen den Befehlscode für das ViewModel bereit, so dass das ViewModel tatsächlich wiederverwendbar ist.

Wir haben auch festgestellt, dass die Sculpture code-gen framework implementiert MVVM und ein Muster, das dem von Prism ähnelt UND es macht auch ausgiebigen Gebrauch von Controllern, um die gesamte Anwendungsfalllogik zu trennen.

Gehen Sie nicht davon aus, dass Controller durch View-Modelle obsolet werden.

Ich habe einen Blog zu diesem Thema gestartet, den ich nach und nach ergänzen werde (nur Archiv, da das Hosting verloren ging) . Es gibt Probleme bei der Kombination von MVCVM mit den gängigen Navigationssystemen, da die meisten Navigationssysteme nur Views und VMs verwenden, aber darauf werde ich in späteren Artikeln eingehen.

Ein zusätzlicher Vorteil der Verwendung eines MVCVM-Modells ist, dass nur die Controller-Objekte müssen während der gesamten Lebensdauer der Anwendung im Speicher vorhanden sein und die Controller enthalten hauptsächlich Code und nur wenige Zustandsdaten (d. h. ein geringer Speicher-Overhead). Dies führt zu wesentlich weniger speicherintensiven Anwendungen als Lösungen, bei denen View-Modelle beibehalten werden müssen, und ist ideal für bestimmte Arten der mobilen Entwicklung (z. B. Windows Mobile mit Silverlight/Prism/MEF). Dies hängt natürlich von der Art der Anwendung ab, da Sie möglicherweise immer noch gelegentlich zwischengespeicherte VMs für die Reaktionsfähigkeit beibehalten müssen.

Hinweis: Dieser Beitrag wurde mehrfach überarbeitet und zielte nicht speziell auf die gestellte Frage ab, so dass ich den ersten Teil aktualisiert habe, um nun auch diese Frage zu behandeln. Ein Großteil der Diskussion in den Kommentaren unten bezieht sich nur auf ASP.Net und nicht auf das Gesamtbild. Dieser Beitrag sollte die breitere Verwendung von MVVM in Silverlight, WPF und ASP.Net abdecken und versuchen, die Leute davon abzuhalten, Controller durch ViewModels zu ersetzen.

Answer 2

Ich denke, der einfachste Weg, um zu verstehen, was diese Akronyme bedeuten sollen, ist, sie einen Moment lang zu vergessen. Denken Sie stattdessen an die Software, mit der sie entstanden sind, und zwar jede einzelne. Im Grunde läuft es auf den Unterschied zwischen dem frühen Web und dem Desktop hinaus.

Als diese Mitte der 2000er Jahre immer komplexer wurden, begann man, das MVC-Softwareentwurfsmuster, das erstmals in den 1970er Jahren beschrieben wurde, auch auf Webanwendungen anzuwenden. Denken Sie an Datenbank, HTML-Seiten und den Code dazwischen. Verfeinern wir dies noch ein wenig, um zu MVC zu gelangen: Für "Datenbank" nehmen wir Datenbank plus Schnittstellencode an. Für "HTML-Seiten" nehmen wir HTML-Vorlagen plus Vorlagenverarbeitungscode an. Für den "Code dazwischen" nehmen wir Code an, der Benutzerklicks auf Aktionen abbildet, möglicherweise die Datenbank beeinflusst und definitiv die Anzeige einer anderen Ansicht verursacht. Das war's, zumindest für die Zwecke dieses Vergleichs.

Lassen Sie uns ein Merkmal dieses Webkrams beibehalten, und zwar nicht so, wie es heute ist, sondern so, wie es vor zehn Jahren existierte, als JavaScript noch ein niederes, verachtenswertes Ärgernis war, das echte Programmierer tunlichst meiden sollten: Die HTML-Seite ist im Wesentlichen stumm und passiv. Der Browser ist ein Thin Client, oder wenn man so will, ein armer Client. Es gibt keine Intelligenz im Browser. Vollständige Seitenneuladungen sind die Regel. Die "Ansicht" wird jedes Mal aufs Neue generiert.

Erinnern wir uns daran, dass diese Art des Webs, obwohl sie der letzte Schrei war, im Vergleich zum Desktop furchtbar rückständig war. Desktop-Anwendungen sind Fat Clients oder Rich Clients, wenn Sie so wollen. (Sogar ein Programm wie Microsoft Word kann als eine Art Client betrachtet werden, ein Client für Dokumente.) Es sind Clients voller Intelligenz, voller Wissen über ihre Daten. Sie sind zustandsorientiert. Sie zwischenspeichern die Daten, die sie verarbeiten, im Speicher. Es gibt keinen solchen Mist wie ein vollständiges Neuladen der Seite.

Und aus dieser Rich-Desktop-Methode stammt wahrscheinlich auch das zweite Akronym: MVVM. Lassen Sie sich nicht von den Buchstaben täuschen, vom Weglassen des C. Controller sind immer noch da. Das müssen sie auch sein. Nichts wird entfernt. Wir fügen nur eine Sache hinzu: Zustandsabhängigkeit, Daten, die auf dem Client zwischengespeichert werden (und damit auch die Intelligenz, mit diesen Daten umzugehen). Diese Daten, im Wesentlichen ein Cache auf dem Client, werden nun "ViewModel" genannt. Sie ermöglichen eine reichhaltige Interaktivität. Und das war's.

• MVC = Model, Controller, View = im Wesentlichen einseitige Kommunikation = geringe Interaktivität
• MVVM = Modell, Controller, Cache, Ansicht = Zwei-Wege-Kommunikation = umfangreiche Interaktivität

Mit Flash, Silverlight und - vor allem - JavaScript hat das Web MVVM angenommen. Browser können nicht mehr zu Recht als Thin Clients bezeichnet werden. Sehen Sie sich ihre Programmierbarkeit an. Sehen Sie sich ihren Speicherverbrauch an. Sehen Sie sich die ganze Javascript-Interaktivität auf modernen Webseiten an.

Ich persönlich finde, dass diese Theorie und das Akronym Business leichter zu verstehen sind, wenn man sich ansieht, worauf sie sich in der konkreten Realität beziehen. Abstrakte Konzepte sind nützlich, vor allem, wenn sie an einer konkreten Sache demonstriert werden, so dass sich der Kreis schließen kann.

Answer 3

MVVM Modell-Ansicht AnsichtModell ist ähnlich wie MVC, Modell-Ansicht-Controller

Der Controller wird ersetzt durch eine ViewModel . Das ViewModel befindet sich unterhalb der UI-Schicht. Das ViewModel stellt die Daten und Befehlsobjekte zur Verfügung, die die Ansicht benötigt. Man könnte es als ein Container-Objekt betrachten, aus dem die View ihre Daten und Aktionen bezieht. Das ViewModel bezieht seine Daten aus dem Model.

Russel Ost führt einen Blog, in dem ausführlicher diskutiert wird Warum ist MVVM ist anders als MVC

Answer 4

Zum einen ist MVVM eine Weiterentwicklung des MVC-Musters, das XAML für die Darstellung verwendet. Dieser Artikel skizziert einige der Facetten der beiden.

Die Hauptaussage der Model/View/ViewModel-Architektur scheint zu sein, dass es über den Daten ("das Model") eine weitere Schicht nicht-visueller Komponenten ("das ViewModel") gibt, die die Konzepte der Daten genauer auf die Konzepte der Ansicht der Daten ("die View") abbilden. Es ist das ViewModel, an das sich die View bindet, nicht das Model direkt.

Answer 5

Microsoft lieferte eine Erklärung des MVVM-Musters in der Windows-Umgebung hier .

Hier ist ein wichtiger Abschnitt:

Beim Model-View-ViewModel-Entwurfsmuster besteht eine Anwendung aus drei allgemeinen Komponenten.

• Modell : Dies stellt das Datenmodell dar, das Ihre Anwendung nutzt. In einer App zur gemeinsamen Nutzung von Bildern könnte diese Schicht zum Beispiel die Menge der auf einem Gerät verfügbaren Bilder und die API zum Lesen und in die Bildbibliothek zu lesen und zu schreiben.

• Siehe : Eine Anwendung besteht in der Regel aus mehreren Seiten der Benutzeroberfläche. Jede Seite, die dem Benutzer angezeigt wird, ist in der MVVM-Terminologie eine Ansicht. Die Ansicht ist der XAML-Code, der zur Definition und Gestaltung dessen, was der Benutzer sieht, verwendet wird. Die Daten aus dem Modell werden dem Benutzer angezeigt, und es ist die Aufgabe des ViewModel, die Benutzeroberfläche mit diesen Daten zu füttern, basierend auf dem aktuellen Zustand der App. In einer App zur gemeinsamen Nutzung von Bildern wären die Views zum Beispiel die UI die dem Benutzer die Liste der Alben auf dem Gerät zeigt, die Bilder in einem Album, und vielleicht eine weitere, die dem Benutzer ein bestimmtes Bild zeigt.

• ViewModel : Das ViewModel verbindet das Datenmodell, oder einfach das Modell, mit der Benutzeroberfläche oder den Ansichten der Anwendung. Es enthält die Logik Logik, mit der die Daten des Modells verwaltet werden, und stellt die Daten als einen Satz von Eigenschaften, an die sich die XAML-Benutzeroberfläche bzw. die Ansichten binden können. Ein Beispiel, in einer App zur gemeinsamen Nutzung von Bildern würde das ViewModel eine Liste von Alben anzeigen, und für jedes Album eine Liste von Bildern anzeigen. Die UI ist unabhängig davon woher die Bilder kommen und wie sie abgerufen werden. Sie weiß einfach eine Reihe von Bildern, wie sie vom ViewModel bereitgestellt werden, und zeigt sie dem Benutzer an.