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

Die anderen Antworten sind für jemanden, der mit dem Thema Architekturmuster nicht sehr vertraut ist, vielleicht nicht leicht zu verstehen. Jemand, der neu in der App-Architektur ist, möchte vielleicht wissen, wie sich seine Wahl in der Praxis auf seine App auswirken kann und was es mit dem ganzen Trubel in den Communities auf sich hat.

Um etwas Licht ins Dunkel zu bringen, habe ich mir dieses Drehbuch mit MVVM, MVP und MVC ausgedacht. Die Geschichte beginnt damit, dass ein Benutzer auf die Schaltfläche "FINDEN" in einer Filmsuch-App klickt :

Benutzer: Klicken Sie

Siehe : Wer ist das? [ MVVM|MVP|MVC ]

Benutzer: Ich habe gerade auf die Suchschaltfläche geklickt

Siehe : Ok, warte kurz . [ MVVM|MVP|MVC ]

( Siehe Aufruf der ViewModel | Präsentator | Controller ) [ MVVM|MVP|MVC ]

Siehe : Hallo ViewModel | Präsentator | Controller Was soll ich tun, wenn ein Benutzer gerade auf die Schaltfläche "Suchen" geklickt hat? [ MVVM|MVP|MVC ]

ViewModel | Präsentator | Controller : Hallo Siehe Gibt es einen Suchbegriff auf dieser Seite? [ MVVM|MVP|MVC ]

Siehe : Ja, hier ist es "Klavier" [ MVVM|MVP|MVC ]

-- Dies ist der wichtigste Unterschied zwischen MVVM UND MVP | MVC ---

Präsentator | Controller : Danke Siehe In der Zwischenzeit suche ich den Suchbegriff in der Modell zeigen Sie ihm/ihr bitte einen Fortschrittsbalken [ MVP | MVC ]

( Präsentator | Controller ruft die Modell ) [ MVP | MVC ]

ViewModel : Danke, ich werde den Suchbegriff im Internet nachschlagen. Modell aber ich werde Sie nicht direkt aktualisieren. Stattdessen werde ich Ereignisse an searchResultsListObservable auslösen, wenn es ein Ergebnis gibt. Sie sollten das also besser beobachten. [ MVVM ]

(Bei der Beobachtung eines beliebigen Auslösers in searchResultsListObservable wird die Siehe ist der Meinung, dass dem Benutzer ein Fortschrittsbalken angezeigt werden sollte, da ViewModel würde nicht mit ihm darüber sprechen)

---------- ---------- ----------

ViewModel | Präsentator | Controller : Hallo Modell Haben Sie einen Treffer für diesen Suchbegriff? "Klavier" [ MVVM | MVP | MVC ]

Modell : Hallo ViewModel | Präsentator | Controller Ich überprüfe das mal [ MVVM | MVP | MVC ]

( Modell macht eine Abfrage an die Filmdatenbank ) [ MVVM | MVP | MVC ]

( Nach einer Weile )

---- Dies ist der Schnittpunkt zwischen MVVM , MVP y MVC -----

Modell : Ich habe eine Liste für Sie gefunden, ViewModel | Präsentator Hier ist es in JSON "[{"name": "Klavierlehrer", "Jahr":2001},{"name": "Klavier", "Jahr":1993}]" [ MVVM | MVP ]

Modell : Es liegt ein Ergebnis vor, Controller. Ich habe eine Feldvariable in meiner Instanz erstellt und sie mit dem Ergebnis gefüllt. Ihr Name ist "searchResultsList" [ MVC ]

( Präsentator | Controller danke Modell und kommt zurück zum Siehe ) [ MVP | MVC ]

Präsentator : Danke fürs Warten Siehe Ich habe eine Liste mit passenden Ergebnissen für Sie gefunden und sie in ein vorzeigbares Format gebracht: ["Klavierlehrer 2001, "Klavier 1993"]. Bitte blenden Sie jetzt auch den Fortschrittsbalken aus [ MVP ]

Controller : Danke fürs Warten Siehe Ich habe Model nach Ihrer Suchanfrage gefragt. Es sagt, dass es eine Liste von übereinstimmenden Ergebnissen gefunden und sie in einer Variablen namens "searchResultsList" innerhalb seiner Instanz gespeichert hat. Sie können sie von dort abrufen. Bitte blenden Sie auch den Fortschrittsbalken aus [ MVC ]

ViewModel : Jeder Beobachter von searchResultsListObservable wird benachrichtigt, dass es diese neue Liste im vorzeigbaren Format gibt: ["Klavierlehrer 2001, "Klavier 1993"].[ MVVM ]

Siehe : Vielen Dank Moderatorin [ MVP ]

Siehe : Dankeschön " Controller " [ MVC ] (Jetzt ist die Siehe stellt sich selbst in Frage: Wie soll ich die Ergebnisse präsentieren, die ich durch die Modell für den Nutzer? Soll das Produktionsjahr des Films an erster oder letzter Stelle stehen?)

Siehe : Oh, es gibt einen neuen Trigger in searchResultsListObservable , gut, es gibt eine vorzeigbare Liste, jetzt muss ich sie nur noch in einer Liste anzeigen. Ich sollte auch den Fortschrittsbalken ausblenden, jetzt wo ich das Ergebnis habe. [ MVVM ]

Falls Sie daran interessiert sind, habe ich eine Reihe von Artikeln geschrieben aquí Vergleich von MVVM, MVP und MVC anhand der Implementierung einer Android-Filmsuch-App.