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

Ich dachte, einer der Hauptunterschiede war, dass in MVC, Ihre V liest Ihre M direkt, und geht über die C, um die Daten zu manipulieren, während in MVVM, Ihre VM fungiert als ein M-Proxy, sowie die Bereitstellung der verfügbaren Funktionalität für Sie V.

Wenn ich mich nicht täusche, bin ich überrascht, dass noch niemand einen Hybrid entwickelt hat, bei dem Ihre VM lediglich ein M-Proxy ist und C die gesamte Funktionalität bereitstellt.

Answer 2

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.

Answer 3

MVC ist eine kontrollierte Umgebung und MVVM ist eine reaktive Umgebung.

In einer kontrollierten Umgebung sollten Sie weniger Code und eine gemeinsame Quelle für die Logik haben, die immer innerhalb des Controllers liegen sollte. In der Webwelt wird MVC jedoch leicht in Logik für die Erstellung von Ansichten und dynamische Logik für Ansichten unterteilt. Die Erstellung erfolgt auf dem Server und die Dynamik auf dem Client. Man sieht dies häufig bei ASP.NET MVC in Kombination mit AngularJS, wobei der Server eine Ansicht erstellt, ein Modell übergibt und es an den Client sendet. Der Client interagiert dann mit der Ansicht, wobei AngularJS als lokaler Controller eingesetzt wird. Nach der Übermittlung wird das Model oder ein neues Model an den Server-Controller zurückgegeben und verarbeitet. (Auf diese Weise setzt sich der Zyklus fort, und es gibt viele andere Übersetzungen dieser Handhabung bei der Arbeit mit Sockets oder AJAX usw., aber insgesamt ist die Architektur identisch).

MVVM ist eine reaktive Umgebung, d.h. Sie schreiben typischerweise Code (wie z.B. Trigger), der auf der Grundlage eines Ereignisses aktiviert wird. In XAML, wo MVVM gedeiht, ist dies alles leicht mit dem eingebauten Datenbindungs-Framework getan, ABER wie erwähnt wird dies auf jedem System in jeder Ansicht mit jeder Programmiersprache funktionieren. Es ist nicht MS-spezifisch. Das ViewModel löst ein Ereignis aus (in der Regel ein Ereignis zur Änderung einer Eigenschaft) und die View reagiert darauf, basierend auf den von Ihnen erstellten Auslösern. Das kann technisch werden, aber im Grunde ist die View zustandslos und ohne Logik. Sie ändert einfach ihren Zustand auf der Grundlage von Werten. Darüber hinaus sind ViewModels zustandslos mit sehr wenig Logik, und Models sind der Zustand mit im Wesentlichen Null Logik, da sie nur den Zustand aufrechterhalten sollen. Ich beschreibe dies als Anwendungszustand (Model), Zustandsübersetzer (ViewModel), und dann den visuellen Zustand / die Interaktion (View).

In einer MVC-Desktop- oder Client-Side-Anwendung sollten Sie ein Modell haben, und das Modell sollte vom Controller verwendet werden. Auf der Grundlage des Modells wird der Controller die Ansicht ändern. Ansichten sind in der Regel über Schnittstellen mit Controllern verbunden, so dass der Controller mit einer Vielzahl von Ansichten arbeiten kann. In ASP.NET ist die Logik für MVC auf dem Server leicht rückwärts gerichtet, da der Controller die Modelle verwaltet und die Modelle an eine ausgewählte Ansicht weitergibt. Die View wird dann auf der Grundlage des Modells mit Daten gefüllt und verfügt über eine eigene Logik (in der Regel ein weiterer MVC-Satz, wie er bei AngularJS verwendet wird). Die Leute werden argumentieren und dies mit Anwendungs-MVC verwechseln und versuchen, beides zu tun, wobei die Aufrechterhaltung des Projekts schließlich zu einer Katastrophe wird. Legen Sie bei der Verwendung von MVC IMMER die Logik und die Kontrolle an einer Stelle ab. Schreiben Sie KEINE View-Logik in den Code hinter der View (oder in die View über JS für das Web), um Controller- oder Modelldaten anzupassen. Lassen Sie den Controller die View ändern. Die EINZIGE Logik, die in einer View enthalten sein sollte, ist die, die zum Erstellen und Ausführen über die verwendete Schnittstelle erforderlich ist. Ein Beispiel hierfür ist die Übermittlung eines Benutzernamens und eines Passworts. Ob auf dem Desktop oder auf der Webseite (auf dem Client), der Controller sollte den Übermittlungsprozess immer dann abwickeln, wenn die View die Submit-Aktion auslöst. Wenn dies richtig gemacht wird, können Sie sich immer leicht in einer MVC-Web- oder lokalen Anwendung zurechtfinden.

MVVM ist persönlich mein Favorit, da es vollständig reaktiv ist. Wenn ein Model seinen Zustand ändert, hört das ViewModel zu und übersetzt diesen Zustand und das war's!!! Die View hört dann auf das ViewModel, wenn sich der Zustand ändert, und aktualisiert sich ebenfalls auf der Grundlage der Übersetzung des ViewModels. Manche Leute nennen es reines MVVM, aber es gibt wirklich nur eines, und es ist mir egal, wie man es argumentiert, und es ist immer reines MVVM, bei dem die View absolut keine Logik enthält.

Hier ist ein kleines Beispiel: Nehmen wir an, Sie möchten ein Menü einblenden, wenn Sie eine Taste drücken. In MVC werden Sie eine MenuPressed-Aktion in Ihrer Schnittstelle haben. Der Controller erkennt, wenn Sie auf die Schaltfläche "Menü" klicken, und teilt dann der Ansicht mit, dass das Menü auf der Grundlage einer anderen Schnittstellenmethode wie SlideMenuIn eingeblendet werden soll. Aus welchem Grund eine Umleitung? Für den Fall, dass der Controller entscheidet, dass Sie es nicht können oder stattdessen etwas anderes tun wollen. Der Controller sollte für die View verantwortlich sein und die View sollte nichts tun, es sei denn, der Controller sagt es. JEDOCH; in MVVM sollte das Schiebe-Menü in der Animation eingebaut und generisch sein, und statt gesagt zu werden, um es zu schieben, wird dies auf der Grundlage eines Wertes geschehen. Es hört also auf das ViewModel und wenn das ViewModel sagt, IsMenuActive = true (oder wie auch immer) die Animation für das stattfindet. Nun, mit dem gesagt, ich möchte einen weiteren Punkt wirklich klar und BITTE beachten. IsMenuActive ist wahrscheinlich BAD MVVM oder ViewModel Design. Wenn man ein ViewModel entwirft, sollte man nie davon ausgehen, dass eine View überhaupt irgendwelche Funktionen hat und nur den Status des übersetzten Modells übergeben. Wenn Sie sich also entscheiden, Ihre Ansicht zu ändern, um das Menü zu entfernen und die Daten/Optionen auf andere Weise anzuzeigen, ist das dem ViewModel egal. Wie würden Sie also das Menü verwalten? Wenn die Daten sinnvoll sind, dann so. Eine Möglichkeit ist, dem Menü eine Liste von Optionen zu geben (wahrscheinlich ein Array von inneren ViewModels). Wenn diese Liste Daten enthält, weiß das Menü, dass es über den Trigger geöffnet werden soll, wenn nicht, weiß es, dass es über den Trigger ausgeblendet werden soll. Sie haben einfach Daten für das Menü oder nicht im ViewModel. Entscheiden Sie NICHT, diese Daten im ViewModel ein- oder auszublenden, sondern übersetzen Sie einfach den Zustand des Models. Auf diese Weise ist die Ansicht vollständig reaktiv und generisch und kann in vielen verschiedenen Situationen verwendet werden.

All dies macht wahrscheinlich absolut keinen Sinn, wenn Sie nicht bereits zumindest ein wenig vertraut mit der Architektur der einzelnen und lernen es kann sehr verwirrend sein, wie Sie viele schlechte Informationen auf dem Netz zu finden.

Also... Dinge, die man beachten sollte, um dies richtig zu machen. Entscheiden Sie im Voraus, wie Sie Ihre Anwendung gestalten wollen, und halten Sie sich daran.

Wenn Sie MVC tun, was großartig ist, dann stellen Sie sicher, dass Sie Controller ist überschaubar und in voller Kontrolle über Ihre Ansicht. Wenn Sie eine große Ansicht haben, sollten Sie in Erwägung ziehen, der Ansicht Steuerelemente hinzuzufügen, die verschiedene Controller haben. Lassen Sie diese Controller jedoch nicht in verschiedene Controller kaskadieren. Die Wartung ist sehr frustrierend. Nehmen Sie sich einen Moment Zeit und entwerfen Sie die Dinge separat, so dass sie als separate Komponenten funktionieren... Und lassen Sie immer den Controller dem Modell sagen, dass es den Speicher festschreiben oder persistieren soll. Das ideale Abhängigkeits-Setup für MVC in ist Ansicht Controller Modell oder mit ASP.NET (lassen Sie mich nicht damit anfangen) Model-View-Controller-Model (wobei Model das gleiche oder ein völlig anderes Model als Controller und View sein kann) ...natürlich ist die einzige Notwendigkeit, den Controller in der View zu kennen, an diesem Punkt hauptsächlich für die Endpunktreferenz, um zu wissen, wohin man ein Model zurückgeben muss.

Wenn Sie MVVM tun, segne ich Ihre gute Seele, aber nehmen Sie sich die Zeit, es RICHTIG zu machen! Verwenden Sie keine Schnittstellen für eine. Lassen Sie Ihre View entscheiden, wie sie auf Basis von Werten aussehen soll. Spielen Sie mit der View mit Mock-Daten. Wenn Sie am Ende eine View haben, die Ihnen ein Menü anzeigt (wie im Beispiel), obwohl Sie es zu dem Zeitpunkt nicht wollten, dann GUT. Ihre Ansicht funktioniert, wie sie sollte und reagiert auf der Grundlage der Werte, wie sie sollte. Fügen Sie einfach ein paar weitere Anforderungen an Ihren Trigger hinzu, um sicherzustellen, dass dies nicht passiert, wenn sich das ViewModel in einem bestimmten übersetzten Zustand befindet, oder befehlen Sie dem ViewModel, diesen Zustand zu leeren. In Ihrem ViewModel entfernen Sie dies NICHT mit interner Logik, als ob Sie von dort aus entscheiden würden, ob die Ansicht es sehen soll oder nicht. Denken Sie daran, dass Sie nicht davon ausgehen können, dass es im ViewModel ein Menü gibt oder nicht. Und schließlich sollte das Model Ihnen nur erlauben, den Zustand zu ändern und höchstwahrscheinlich zu speichern. Hier findet die Validierung und alles andere statt; wenn das Model beispielsweise den Zustand nicht ändern kann, wird es sich einfach als schmutzig oder so markieren. Wenn das ViewModel dies erkennt, wird es übersetzen, was schmutzig ist, und die View wird dies dann erkennen und einige Informationen über einen anderen Trigger anzeigen. Alle Daten in der View können an das ViewModel gebunden werden, so dass alles dynamisch sein kann, nur das Model und das ViewModel haben absolut keine Ahnung, wie die View auf die Bindung reagieren wird. Tatsächlich hat das Model auch keine Ahnung von einem ViewModel. Beim Einrichten von Abhängigkeiten sollten sie so und nur so zeigen Ansicht ViewModel Model (und eine Randbemerkung hier... und das wird wahrscheinlich auch bestritten werden, aber das ist mir egal... ÜBERGEBEN SIE DAS MODELL NICHT an die VIEW, es sei denn, das MODELL ist unveränderlich; andernfalls verpacken Sie es mit einem richtigen ViewModel. Die View sollte kein Model sehen, Punkt. Ich gebe einen Rattenschwanz darauf, welche Demo Sie gesehen haben oder wie Sie es gemacht haben, das ist falsch).

Hier ist mein letzter Tipp... Schauen Sie sich eine gut gestaltete, aber sehr einfache MVC-Anwendung an und machen Sie dasselbe mit einer MVVM-Anwendung. Die eine wird mehr Kontrolle mit begrenzter bis gar keiner Flexibilität haben, während die andere keine Kontrolle und unbegrenzte Flexibilität hat.

Eine kontrollierte Umgebung eignet sich gut für die Verwaltung der gesamten Anwendung von einer Reihe von Controllern oder (einer einzigen Quelle) aus, während eine reaktive Umgebung in separate Repositories aufgeteilt werden kann, ohne dass man überhaupt weiß, was der Rest der Anwendung tut. Mikroverwaltung vs. freie Verwaltung.

Wenn ich Sie nicht genug verwirrt habe, versuchen Sie, mich zu kontaktieren... Es macht mir nichts aus, dies im Detail mit Illustrationen und Beispielen zu erläutern.

Letzten Endes sind wir alle Programmierer und damit lebt die Anarchie in uns, wenn wir programmieren... Es werden also Regeln gebrochen, Theorien geändert, und all das ist am Ende nur noch Makulatur... Aber wenn man an großen Projekten und in großen Teams arbeitet, hilft es wirklich, sich auf ein Entwurfsmuster zu einigen und es durchzusetzen. Eines Tages werden sich die kleinen zusätzlichen Schritte, die am Anfang gemacht werden, später als große Einsparungen erweisen.

Answer 4

Einfacher Unterschied: (Inspiriert von Yaakovs Coursera AngularJS-Kurs)

MVC (Model-View-Controller)

1. Modelle: Modelle enthalten Dateninformationen. Ruft Controller und View nicht auf und verwendet sie nicht. Enthält die Geschäftslogik und Möglichkeiten zur Darstellung von Daten. Einige dieser Daten können in irgendeiner Form in der Ansicht angezeigt werden. Es kann auch Logik zum Abrufen der Daten aus einer Quelle enthalten.
2. Controller: Dient als Verbindung zwischen View und Model. Die Ansicht ruft den Controller auf und der Controller ruft das Modell auf. Im Grunde informiert er das Modell und/oder die Ansicht, um sie entsprechend zu ändern.
3. Ansicht: Beschäftigt sich mit dem UI-Teil. Interagiert mit dem Benutzer.

MVVM (Modell-Sicht-Ansicht-Modell)

ViewModel :

1. Es handelt sich um die Darstellung des Zustands der Ansicht.
2. Sie enthält die Daten, die in der Ansicht angezeigt werden.
3. Reagiert auf Ansichtsereignisse, auch Präsentationslogik genannt.
4. Ruft andere Funktionalitäten für die Verarbeitung der Geschäftslogik auf.
5. Fordert die Ansicht niemals direkt auf, etwas anzuzeigen.

Answer 5

MVVM ist eine (umstrittene) Verfeinerung des Präsentation Modell Muster. Ich sage fragwürdig, weil der einzige Unterschied darin besteht, wie WPF die Möglichkeit bietet, Datenbindung und Befehlsbearbeitung durchzuführen.