MVP Vs MVVM - warum

Question

Ich verwendete MVP, als ich mit Winform arbeitete. Aber ich bin zu MVVM gewechselt, als ich anfing, mit WPF oder Silverlight zu spielen.

Das einzige, was ich bemerkte, ist, dass wir nicht brauchen, um mit den Daten zwischen View und ViewModel in MVVM Muster wegen der starken Bindung zu synchronisieren.

Meine Frage ist ~

1) Bindung (das hilft uns nicht anzeigen und Ansichtsmodell manuell zu synchronisieren) die Verwendung von MVVM der einzige Vorteil ist.

2) Gibt es einen anderen Vorteil MVVM über MVP? Was sind die Unterschiede?

3) Der folgende Code ist MVVP-Muster oder MVVM oder beides?

Danke.

Answer 1

Beispiel ist MVP, eindeutig durch diese Linie definiert:

view.showMessage("This is a msg"); 

Während Code von MVP und MVVM was trivialen Beispielen ähnlich aussehen, diese Muster signifikant verschieden sind. Wenn Sie vermuten, dass MVVM nur der Name von Microsoft für MVP ist, ist es nicht.

Es ist Microsofts Name für ein weniger bekanntes PM (Presentation Model) -Muster - Sie können die Beschreibung nachlesen.

Answer 2

Ich weiß, dass Ihre Frage vor zwei Jahren gestellt wurde, aber ich würde gerne nach über einem Jahr mit MVVM arbeiten.

-1- Ich bin mir nicht sicher, was Sie fragen, aber ich denke, Sie fragen: Ist der einzige Vorteil für MVVM verbindlich? Die Antwort ist nein. Trennung von Bedenken, Bindung und effizientes Testen sind wesentliche Vorteile für MVVM. Es gibt viele kleine Vorteile, aber ich werde nicht auf diese eingehen. Das Binden ist absolut wunderbar, weil alle Synchronisationen automatisiert sind, was weniger Arbeit für Sie bedeutet. Außerdem bedeutet die Trennung von Bedenken, dass das Ansichtsmodell nicht vom Typ der Ansicht abhängt, sodass Sie mehrere Ansichten mit demselben Ansichtsmodell verwenden können. Angenommen, Sie erstellen ein Ansichtsmodell namens ErrorDataViewModel. Der Zweck dieser Klasse besteht darin, eine Liste von ErrorType-Klassen zu halten, die dem Benutzer angezeigt werden. Der ErrorType zeigt grundsätzlich Fehlerinformationen an. Das ErrorDataViewModel verfügt auch über eine boolesche Eigenschaft namens AllErrorsFixed, die dem Benutzer anzeigt, ob alle Fehler in der Liste behoben wurden. AllErrorsFixed ist eine einfache Eigenschaft, die linq verwendet, um die Liste der ErrorTypes.Fixed-Eigenschaft abzufragen. Wenn Alle fest sind, gibt AllErrorsFixed true zurück.

In Anwendung1 möchte Ihr Kunde Fehler in einer einfachen Raster-ähnlichen Weise angezeigt. Sie müssen lediglich ein Raster an die Fehlerliste dieses Ansichtsmodells binden. In Application2 möchte Ihr Kunde, dass die Fehler in einem Navigationsformat angezeigt werden, in dem sie jedes Fehlerformular per Formular anzeigen können. Alles, was Sie dann tun, ist, Ihr Formularsteuerelement an jeden Fehler in der Liste zu binden und Ihre Navigation einzurichten, um von einem Datensatz zum anderen zu wechseln. Aber warten Sie, wenn wir wollen, dass App1 sowohl eine Raster- als auch eine Form-für-Formular-Navigation verwendet, können wir das tun. Noch besser, wenn Sie jetzt eine Webschnittstelle mit Silverlight implementieren möchten, um entweder Application1/Application2 oder ein anderes Produktangebot zu ersetzen, müssen Sie das Ansichtsmodell nicht ändern. Arbeit ist erledigt.

Ich erwähnte den booleschen Wert ErrorsFixed, naja, wir haben vergessen, das in unseren Anwendungen zu implementieren. Alles, was ich tun muss, ist in meine Ansichten zu gehen, ein Steuerelement oder eine Spalte oder einen Eigenschaftentester hinzuzufügen und es an die boolesche Eigenschaft zu binden, und du bist fertig.

In Bezug auf die Prüfung können Tests effizienter sein, da Sie Testcode schreiben können Änderungen innerhalb des Viewmodel die Anwendungen laufen, ohne Zeit zu validieren und die Ansichten zu öffnen. Dies löst nicht alle Testprobleme, aber viele zeitaufwendige Schritte entfallen.

-2- Gibt es einen Vorteil für MVVM oder MVP? Ja. Ein Plakat war falsch, als er sagte, dass eine Ansicht mehrere VMs in MVVM haben kann. Tatsächlich kann eine VM mehrere Ansichten haben, da sie nicht an eine Ansicht gebunden ist. Anders gesagt, mehrere Ansichten können eine VM verwenden. In Ihrem Beispiel, in dem Sie view.ShowMessage() aufrufen, würde dies in MVVM nicht passieren, da Sie nicht garantieren können, dass die Ansicht (WPF oder Silverlight oder Testklasse) über eine ShowMessage-Methode verfügt. Stattdessen feuern Sie ein Ereignis ab. In der Tat ist Prism großartig, da es Aggregatoren für Ereignisse enthält. Wenn Sie also ein Ereignis auslösen, übernimmt der Ereignisaggregator das Senden des Ereignisses an die Ansicht, die dem Ereignis zugewiesen ist. Daher kann die Ansicht jeder App das Ereignis so handhaben, wie es für richtig erachtet wird. Mit MVP müssen Sie einen Presenter für jede Ansicht erstellen. Dies ist extrem zeitaufwendig.

-3- Ihr Beispielcode ist MVP.

Answer 3

Ich habe eine ähnliche Frage vor beantwortet, aber man könnte es auch für Sie nützlich sein:

Die wichtigsten Eigenschaften der beiden von ihnen für den Einsatz in Android-Umgebung.

MVP-Muster:

• Besteht aus Model, View und Presenter Schichten;

• Delegiertenbenutzereingabe in Presenter anzeigen; beide Schichten sollten eine 1 zu 1 Relation haben;

• Ansicht und Modell sind nicht eng gekoppelt ist, um eine klare Trennung von
  betrifft;

• Ansicht verbindet sich über Datenbindung direkt mit dem Modell;

• Einfache Unit-Tests, als eine Schnittstelle für Presenter-Layer 1 schnell mock;

MVVM Muster:

Inklusive drei Schlüsselkomponenten:

• Model (Geschäftsregeln, Datenzugriff, Klassen),

• Ansicht (Benutzeroberfläche),

• ViewModel (als Agent zwischen Ansicht und Modell);
• Hervorragende Lösung für Aufgaben im Zusammenhang mit Windows-Präsentation Foundation System (WPF) und Silverlight Application Framework;
• Bietet eine klarere Trennung der UI- und Anwendungslogik;
• Unit-Tests noch einfacher, da keine Abhängigkeit von der Ansicht ist

Funktionsvergleich

Lasst uns das Wesentliche von MVP vs MVVM zusammen zu vergleichen. Wir sollten auch betonen, dass wir nicht für ein oder ein Muster eintreten.

Code-Metriken: MVP kann mehr Klassen und Java-Code produzieren. In MVVM gibt es mehr Java-Klassen, aber weniger Code pro Klasse.

Wartbarkeit: MVP ist leicht zu erlernen, zu ergänzen, Funktionen hinzuzufügen. Das Hinzufügen neuer Features mit MVVM erfordert möglicherweise einige Erfahrung mit der Bibliothek.

Logik: In MVP ist die Ansicht tatsächlich Ihre Anwendung, während Presenter den App-Fluss verarbeitet. In MVVM-Codeklassen (ViewModel) befindet sich die Anwendung, während die Ansicht die Schnittstelle ist, über die Benutzer mit der App interagieren können.

Dateneingabe: Beginnt mit der Ansicht in MVP, nicht der Presenter. Die Eingabe in MVVM beginnt mit der Ansicht und nicht mit dem ViewModel.

Zuordnung und Referenzen: Eins-zu-Eins-Zuordnung zwischen der Ansicht und dem Presenter in MVP, keine Referenz zwischen ihnen. One-to-Many-Mapping zwischen View und ViewModel in MVVM, keine Referenz.

Abschließende Worte

Offensichtlich entwickeln Architekturmuster. MVVM hat die Tendenz, ein wirklich ordentliches und ängstliches Werkzeug zu werden. Inzwischen ist MVP-Muster flexibel genug, bereits von verschiedenen Bibliotheken profitieren.

Was ist auch klar ist, dass Sie nicht streng mit MVP oder MVVM bleiben müssen. In den meisten Fällen können wir eine App nicht rein auf einem einzigen Muster aufbauen, und das ist in Ordnung. Die Hauptsache ist, die Sicht, das Modell und die Logik zwischen ihnen zu trennen.

Wann MVP verwenden und wann MVVM verwenden, fragen Sie vielleicht? Der Rat verbirgt sich eher in der Datenbindung. In Fällen, in denen eine Bindung mit Datenkontext nicht möglich ist, bevorzugen die meisten Entwickler MVP (Windows Forms ist ein gutes Beispiel). MVVM ist in Fällen bevorzugt, in denen eine Bindung mit Datenkontext möglich ist, da weniger Schnittstellen und weniger Code zu warten sind.

von den Materialien des blog

Answer 4

Sowohl MVP und MVVM Derivate von MVC (siehe Fristen und wie sich diese entwickelt haben). Der Hauptunterschied zwischen ihnen ist die Abhängigkeit, die jede Ebene auf anderen Ebenen hat, und auch, wie stark sie aneinander gebunden sind.

MVC: Framework-Bibliothek

Client Side Backbone.js, knockback.js, Spine.js, Angularjs.

Server Side ASP.NET MVC, Spring MVC Ruby-on-Rails

MVP: Framework-Bibliothek

Client Side Riot.js, GWT

Server Side ASP.NET , JSP Servlets

MVVM: Rahmenbibliothek

Client Side Knockout.js, Kendo (MVVM)

Server Side WPF (Desktop) oder Silverlight, Windows Phone-Anwendungen (XAML), Adobe Flex

So die spezifische Frage zu beantworten: Ja, mit Ausnahme der Zweiwege-Bindung in MVVM, ViewModel macht ein Observable verfügbar, das der Hauptvorteil von MVVM ist, das Zweiwegedaten bindet.