Was sind MVP und MVC und worin besteht der Unterschied?

Question

Beim Blick über den Tellerrand RAD (Ziehen und Konfigurieren) bei der Erstellung von Benutzeroberflächen, die von vielen Tools unterstützt werden, werden Sie wahrscheinlich auf drei Entwurfsmuster stoßen, die Modell-Ansichts-Steuerung , Modell-Ansicht-Präsentator y Model-View-ViewModel . Meine Frage besteht aus drei Teilen:

1. Welche Themen werden in diesen Mustern angesprochen?
2. Inwiefern sind sie sich ähnlich?
3. Wie unterscheiden sie sich?

Answer 1

Außerdem sollte man nicht vergessen, dass es auch verschiedene Arten von MVPs gibt. Fowler hat das Muster in zwei unterteilt - Passive View und Supervising Controller.

Bei der Verwendung der passiven Ansicht implementiert Ihre Ansicht in der Regel eine feinkörnige Schnittstelle mit Eigenschaften, die mehr oder weniger direkt auf das darunter liegende UI-Widget abgebildet werden. Sie könnten zum Beispiel eine ICustomerView mit Eigenschaften wie Name und Adresse haben.

Ihre Implementierung könnte etwa so aussehen:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

Ihre Presenter-Klasse wird mit dem Modell sprechen und es der Ansicht "zuordnen". Dieser Ansatz wird als "Passive View" bezeichnet. Der Vorteil ist, dass die Ansicht einfach zu testen ist und sich leichter zwischen verschiedenen UI-Plattformen (Web, Windows/XAML usw.) verschieben lässt. Der Nachteil ist, dass Sie Dinge wie die Datenbindung nicht nutzen können (das ist wirklich leistungsstark in Frameworks wie WPF y Silberlicht ).

Die zweite Variante von MVP ist der überwachende Controller. In diesem Fall könnte Ihre Ansicht eine Eigenschaft namens Customer haben, die wiederum mit den UI-Widgets databound ist. Sie müssen sich nicht um die Synchronisierung und das Mikromanagement der View kümmern, und der überwachende Controller kann bei Bedarf eingreifen und helfen, z. B. mit kompletter Interaktionslogik.

Die dritte "Variante" von MVP (oder jemand würde sie vielleicht als separates Muster bezeichnen) ist das Präsentationsmodell (oder manchmal auch Model-View-ViewModel genannt). Im Vergleich zum MVP "verschmelzen" Sie das M und das P in einer Klasse. Sie haben Ihr Kundenobjekt, an das Ihre UI-Widgets datengebunden sind, aber Sie haben auch zusätzliche UI-spezifische Felder wie "IsButtonEnabled", oder "IsReadOnly", usw.

Ich denke, die beste Ressource, die ich zur UI-Architektur gefunden habe, ist die Serie von Blogbeiträgen von Jeremy Miller auf der Seite Die Build Your Own CAB-Serie Inhaltsverzeichnis . Er behandelte alle Arten von MVP und zeigte C#-Code, um sie zu implementieren.

Ich habe auch über das Model-View-ViewModel-Muster im Kontext von Silverlight gebloggt, und zwar unter YouCard erneut besucht: Die Implementierung des ViewModel-Musters .

Answer 2

Beide Rahmenwerke zielen darauf ab, verschiedene Aspekte voneinander zu trennen - zum Beispiel die Interaktion mit einer Datenquelle (Modell), die Anwendungslogik (oder die Umwandlung dieser Daten in nützliche Informationen) (Controller/Presenter) und den Anzeigecode (View). In einigen Fällen kann das Modell auch verwendet werden, um eine Datenquelle in eine höhere Abstraktionsebene zu verwandeln. Ein gutes Beispiel hierfür ist die MVC Schaufenster Projekt .

Es gibt eine Diskussion aquí über die Unterschiede zwischen MVC und MVP.

Der Unterschied besteht darin, dass in einer MVC-Anwendung traditionell die Ansicht und der Controller mit dem Modell interagieren, aber nicht miteinander.

Bei MVP-Entwürfen hat der Präsentator Zugriff auf das Modell und interagiert mit der Ansicht.

Abgesehen davon ist ASP.NET MVC nach diesen Definitionen ein MVP-Framework, weil der Controller auf das Modell zugreift, um die Ansicht zu füllen, die keine Logik haben soll (sie zeigt nur die vom Controller bereitgestellten Variablen an).

Um vielleicht eine Vorstellung von der ASP.NET MVC-Unterscheidung von MVP zu bekommen, sehen Sie sich diese MIX-Präsentation von Scott Hanselman.

Answer 3

Beides sind Muster, die versuchen, Präsentation und Geschäftslogik zu trennen und die Geschäftslogik von UI-Aspekten zu entkoppeln

Architektonisch ist MVP ein auf Page Controller basierender Ansatz, während MVC ein auf Front Controller basierender Ansatz ist. Das bedeutet, dass in MVP der Lebenszyklus von Standard-Webformularen durch die Extraktion der Geschäftslogik aus dem dahinter liegenden Code erweitert wird. Mit anderen Worten, die Seite ist derjenige, der die http-Anfrage bedient. Mit anderen Worten, MVP ist IMHO eine evolutionäre Art der Verbesserung von Web-Formularen. MVC hingegen ändert das Spiel komplett, denn die Anfrage wird von der Controller-Klasse abgefangen, bevor die Seite geladen wird, die Geschäftslogik wird dort ausgeführt und am Ende der Controller-Verarbeitung werden die Daten einfach auf der Seite ("View") abgelegt. In diesem Sinne sieht MVC (zumindest für mich) sehr nach der Supervising Controller-Variante von MVP aus, erweitert um eine Routing-Engine.

Beide ermöglichen TDD und haben Vor- und Nachteile.

Entscheidung über die Wahl einer von ihnen IMHO sollte auf, wie viel Zeit man in ASP NET Web-Formular Art von Web-Entwicklung investiert basieren. Wenn man sich selbst als gut in Web-Formularen betrachten würde, würde ich MVP vorschlagen. Wenn man nicht so komfortabel in Dinge wie Seite Lebenszyklus etc MVC fühlen würde, könnte ein Weg, hier zu gehen.

Hier ist ein weiterer Link zu einem Blogbeitrag, der etwas mehr Details zu diesem Thema enthält

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Answer 4

Ich habe sowohl MVP als auch MVC verwendet, und obwohl wir als Entwickler dazu neigen, uns auf die technischen Unterschiede der beiden Muster zu konzentrieren, ist der Punkt für MVP IMHO viel mehr mit der Einfachheit der Einführung verbunden als alles andere.

Wenn ich in einem Team arbeite, das bereits einen guten Hintergrund in der Entwicklung von Webformularen hat, ist es viel einfacher, MVP als MVC einzuführen. Ich würde sagen, dass MVP in diesem Szenario ein schneller Gewinn ist.

Meiner Erfahrung nach ist es relativ einfach, ein Team von Webformulare auf MVP und dann von MVP auf MVC umzustellen; die Umstellung von Webformulare auf MVC ist schwieriger.

Ich hinterlasse hier einen Link zu einer Reihe von Artikeln, die ein Freund von mir über MVP und MVC veröffentlicht hat.

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

Answer 5

In MVP bezieht die Ansicht Daten aus dem Präsentator, der Daten aus dem Modell zeichnet und vorbereitet/normalisiert, während in MVC der Controller Daten aus dem Modell bezieht und festlegt, indem er sie in die Ansicht schiebt.

In MVP können Sie eine einzelne Ansicht mit mehreren Präsentatoren und einen einzelnen Präsentator mit verschiedenen Ansichten arbeiten lassen.

MVP verwendet in der Regel eine Art Bindungsframework, z. B. das Microsoft WPF-Bindungsframework oder verschiedene Bindungsframeworks für HTML5 und Java.

In diesen Frameworks weiß das UI/HTML5/XAML, welche Eigenschaft des Presenters jedes UI-Element anzeigt. Wenn Sie also einen View an einen Presenter binden, sucht der View nach den Eigenschaften und weiß, wie er Daten von ihnen abrufen kann und wie er sie einstellen muss, wenn ein Wert in der UI vom Benutzer geändert wird.

Wenn es sich bei dem Modell beispielsweise um ein Auto handelt, dann ist der Präsentator eine Art Autopräsentator, der die Eigenschaften des Autos (Baujahr, Hersteller, Sitze usw.) für die Ansicht bereitstellt. Die Ansicht weiß, dass das Textfeld mit der Bezeichnung "Autohersteller" die Eigenschaft "Hersteller" des Präsentators anzeigen muss.

Sie können dann viele verschiedene Arten von Presentern an die Ansicht binden, alle müssen die Eigenschaft Maker haben - es kann ein Flugzeug, ein Zug oder was auch immer sein, der Ansicht ist das egal. Die Ansicht bezieht Daten aus dem Präsentator - egal welcher - solange er eine vereinbarte Schnittstelle implementiert.

Dieses Bindungs-Framework ist, wenn man es zerlegt, eigentlich der Controller :-)

Sie können MVP also als eine Weiterentwicklung von MVC betrachten.

MVC ist toll, aber das Problem ist, dass in der Regel seine Controller pro Ansicht. Controller A weiß, wie man Felder von View A einstellt. Wenn Sie nun wollen, dass View A Daten von Modell B anzeigt, müssen Sie Controller A das Modell B kennen, oder Sie brauchen Controller A, um ein Objekt mit einer Schnittstelle zu erhalten - was wie MVP ist, nur ohne die Bindungen, oder Sie müssen den UI-Set-Code in Controller B neu schreiben.

Fazit - MVP und MVC sind beide von UI-Mustern entkoppelt, aber MVP verwendet in der Regel ein Bindungs-Framework, das MVC zugrunde liegt. Dementsprechend ist MVP auf einer höheren architektonischen Ebene als MVC und ein Wrapper-Muster über MVC.