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

Modell-Ansicht-Präsentator

Sur MVP Der Presenter enthält die UI-Geschäftslogik für die View. Alle Aufrufe der Ansicht werden direkt an den Presenter delegiert. Der Presenter ist auch direkt von der View entkoppelt und kommuniziert mit ihr über eine Schnittstelle. Dies soll das Mocking der View in einem Unit-Test ermöglichen. Ein gemeinsames Merkmal von MVP ist, dass es eine Menge von Zwei-Wege-Dispatching geben muss. Wenn zum Beispiel jemand auf die Schaltfläche "Speichern" klickt, delegiert der Event-Handler an die "OnSave"-Methode des Presenters. Sobald der Speichervorgang abgeschlossen ist, ruft der Präsentator die Ansicht über seine Schnittstelle zurück, so dass die Ansicht anzeigen kann, dass der Speichervorgang abgeschlossen ist.

MVP ist ein sehr natürliches Muster, um eine getrennte Darstellung in WebForms zu erreichen. Der Grund dafür ist, dass die Ansicht immer zuerst von der ASP.NET-Laufzeit erstellt wird. Sie können Erfahren Sie mehr über beide Varianten .

Zwei Hauptvarianten

Passive Ansicht: Die Ansicht ist so dumm wie möglich und enthält fast keine Logik. Ein Presenter ist ein Mittelsmann, der mit der Ansicht und dem Modell spricht. Die Ansicht und das Modell sind vollständig voneinander abgeschirmt. Das Model kann Ereignisse auslösen, aber der Presenter abonniert diese, um die View zu aktualisieren. In der passiven Ansicht gibt es keine direkte Datenbindung, stattdessen stellt die Ansicht Setter-Eigenschaften zur Verfügung, die der Präsentator zum Setzen der Daten verwendet. Der gesamte Zustand wird im Presenter und nicht in der Ansicht verwaltet.

• Pro: maximale Testbarkeit der Oberfläche; saubere Trennung von View und Model
• Nachteil: mehr Arbeit (z. B. alle Setter-Eigenschaften), da Sie die gesamte Datenbindung selbst vornehmen.

Aufsichtsführender Controller: Der Presenter verarbeitet Benutzergesten. Die Ansicht bindet sich durch Datenbindung direkt an das Modell. In diesem Fall ist es die Aufgabe des Presenters, das Model an die View weiterzugeben, damit diese sich daran binden kann. Der Presenter enthält auch die Logik für Gesten wie das Drücken einer Schaltfläche, die Navigation usw.

• Pro: Durch die Nutzung der Datenbindung wird der Umfang des Codes reduziert.
• Nachteil: Es gibt eine weniger testbare Oberfläche (wegen der Datenbindung), und es gibt weniger Kapselung in der Ansicht, da sie direkt mit dem Modell spricht.

Modell-Ansichts-Steuerung

In der MVC Der Controller ist dafür verantwortlich, zu bestimmen, welche Ansicht als Reaktion auf eine beliebige Aktion angezeigt werden soll, auch wenn die Anwendung geladen wird. Dies unterscheidet sich von MVP, wo Aktionen über die View zum Presenter geleitet werden. In MVC korreliert jede Aktion in der View mit einem Aufruf eines Controllers zusammen mit einer Aktion. Im Web beinhaltet jede Aktion einen Aufruf an eine URL, auf deren anderer Seite ein Controller steht, der darauf antwortet. Sobald dieser Controller seine Verarbeitung abgeschlossen hat, gibt er die richtige Ansicht zurück. Die Abfolge setzt sich während der gesamten Lebensdauer der Anwendung auf diese Weise fort:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

Ein weiterer großer Unterschied zu MVC ist, dass die Ansicht nicht direkt an das Modell gebunden ist. Der View rendert einfach und ist völlig zustandslos. In MVC-Implementierungen hat die View normalerweise keine Logik im Code dahinter. Dies steht im Gegensatz zu MVP, wo dies absolut notwendig ist, denn wenn die View nicht an den Presenter delegiert, wird sie nie aufgerufen.

Präsentation Modell

Ein weiteres Muster, das man sich ansehen sollte, ist die Präsentation Modell Muster. Bei diesem Muster gibt es keinen Presenter. Stattdessen bindet sich die Ansicht direkt an ein Präsentationsmodell. Das Präsentationsmodell ist ein Modell, das speziell für die Ansicht erstellt wurde. Das bedeutet, dass dieses Modell Eigenschaften aufweisen kann, die man niemals in ein Domänenmodell einfügen würde, da dies eine Verletzung der Gewaltenteilung darstellen würde. In diesem Fall bindet sich das Präsentationsmodell an das Domänenmodell und kann Ereignisse abonnieren, die von diesem Modell kommen. Die Ansicht abonniert dann Ereignisse, die vom Präsentationsmodell kommen, und aktualisiert sich entsprechend. Das Präsentationsmodell kann Befehle bereitstellen, die die Ansicht zum Aufrufen von Aktionen verwendet. Der Vorteil dieses Ansatzes besteht darin, dass Sie den Code-Behind im Wesentlichen vollständig entfernen können, da das PM das gesamte Verhalten des Views vollständig kapselt. Dieses Muster ist ein sehr guter Kandidat für den Einsatz in WPF-Anwendungen und wird auch als Model-View-ViewModel .

Es gibt eine MSDN-Artikel über das Präsentationsmodell und einen Abschnitt in der Anleitung für zusammengesetzte Anwendungen für WPF (ehemals Prism) über Getrennte Darstellungsmuster

Answer 2

Dies ist eine grobe Vereinfachung der vielen Varianten dieser Entwurfsmuster, aber so stelle ich mir die Unterschiede zwischen den beiden vor.

MVC

MVP

Answer 3

Darüber habe ich vor einiger Zeit in einem Blog geschrieben, mit einem Zitat von Todd Snyder's ausgezeichneter Beitrag über den Unterschied zwischen den beiden :

Hier sind die wichtigsten Unterschiede zwischen den Mustern:

MVP-Muster

• Die Ansicht ist lockerer an das Modell gekoppelt. Der Präsentator ist verantwortlich für die Bindung des Modells an die Ansicht.
• Einfacher zu testen, da die Interaktion mit der Ansicht über eine Schnittstelle
• In der Regel ist die Zuordnung von Zuschauer zu Moderator eins zu eins. Komplexe Ansichten können mehrere Präsentatoren haben.

MVC-Muster

• Controller basieren auf Verhaltensweisen und können übergreifend genutzt werden Ansichten
• Kann für die Bestimmung der anzuzeigenden Ansicht verantwortlich sein

Dies ist die beste Erklärung, die ich im Internet finden konnte.

Answer 4

Hier sind Abbildungen, die den Kommunikationsfluss darstellen

Answer 5

MVP ist pas notwendigerweise ein Szenario, in dem die Ansicht das Sagen hat (siehe z. B. MVP von Taligent).
Ich finde es bedauerlich, dass dies immer noch als Muster (View in charge) und nicht als Anti-Muster gepredigt wird, denn es widerspricht "It's just a view" (Pragmatic Programmer). "It's just a view" besagt, dass die endgültige Ansicht, die dem Benutzer gezeigt wird, für die Anwendung zweitrangig ist. Das MVP-Muster von Microsoft erschwert die Wiederverwendung von Views erheblich und Bequem entschuldigt Microsofts Designer, schlechte Praktiken zu fördern.

Um ganz offen zu sein, denke ich, dass die zugrundeliegenden Anliegen von MVC für jede MVP-Implementierung gelten und die Unterschiede fast ausschließlich semantischer Natur sind. Solange Sie die Trennung der Belange zwischen der Ansicht (die die Daten anzeigt), dem Controller (der die Benutzerinteraktion initialisiert und steuert) und dem Modell (die zugrundeliegenden Daten und/oder Dienste) einhalten, erreichen Sie die Vorteile von MVC. Wenn Sie diese Vorteile erreichen, dann ist es völlig egal, ob Ihr Muster MVC, MVP oder Supervising Controller heißt. Das einzige real Muster bleibt als MVC, der Rest sind nur unterschiedliche Geschmacksrichtungen von ihm.

Erwägen Sie ce hochinteressanter Artikel, der eine Reihe dieser unterschiedlichen Implementierungen umfassend auflistet. Sie werden feststellen, dass sie im Grunde alle das Gleiche tun, nur etwas anders.

Ich persönlich bin der Meinung, dass MVP erst vor kurzem wieder als eingängiger Begriff eingeführt wurde, um entweder die Streitigkeiten zwischen semantischen Fanatikern zu verringern, die darüber streiten, ob etwas wirklich MVC ist oder nicht, oder um Microsofts Rapid Application Development Tools zu rechtfertigen. Keiner dieser beiden Gründe rechtfertigt meiner Meinung nach seine Existenz als eigenständiges Entwurfsmuster.