Frage Was sind MVP und MVC und was ist der Unterschied?


Wenn man über die RAD (Drag-Drop und konfigurieren) Weg zum Erstellen von Benutzeroberflächen, die viele Werkzeuge Sie ermutigen, sind wahrscheinlich drei Design-Muster genannt Model View Controller, Modellansicht-Presenter und Modell-Ansicht-AnsichtModell. Meine Frage besteht aus drei Teilen:

  1. Welche Probleme adressieren diese Muster?
  2. Wie sind sie ähnlich?
  3. Wie sind sie anders?

1834
2017-08-05 10:06


Ursprung


Antworten:


Modellansicht-Presenter

Im MVPDer Presenter enthält die UI-Geschäftslogik für die Ansicht. Alle Aufrufe von View delegieren direkt an Presenter. Der Presenter ist auch direkt vom View entkoppelt und kommuniziert über eine Schnittstelle mit ihm. Dies dient dazu, die Ansicht in einem Komponententest zu verspotten. Eine häufige Eigenschaft von MVP ist, dass es viel Zweiwege-Dispatching geben muss. Wenn zum Beispiel jemand auf die Schaltfläche "Speichern" klickt, wird der Event-Handler an die "OnSave" -Methode des Presenters delegiert. Sobald der Speichervorgang abgeschlossen ist, ruft der Präsentator die Ansicht über seine Schnittstelle zurück, sodass die Ansicht anzeigen kann, dass die Speicherung abgeschlossen ist.

MVP neigt dazu, ein sehr natürliches Muster zu sein, um eine getrennte Darstellung in Web Forms 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 Hauptvariationen

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

  • Pro: maximale Testbarkeitsfläche; saubere Trennung von Ansicht und Modell
  • Con: mehr Arbeit (zum Beispiel alle Setter-Eigenschaften), da Sie alle Daten selbst binden.

Überwachender Controller: Der Presenter handhabt Benutzergesten. Die Ansicht wird direkt durch Datenbindung an das Modell gebunden. In diesem Fall ist es Aufgabe des Presenters, das Modell an die Ansicht zu übergeben, damit es an es gebunden werden kann. Der Presenter enthält auch eine Logik für Gesten wie das Drücken einer Taste, Navigation usw.

  • Pro: Durch Databinding wird die Menge an Code reduziert.
  • Con: Es gibt weniger testbare Oberfläche (wegen der Datenbindung) und es gibt weniger Verkapselung in der Ansicht, da es direkt mit dem Modell kommuniziert.

Model View Controller

In dem MVCDer Controller ist verantwortlich für die Entscheidung, welche View als Reaktion auf eine Aktion angezeigt werden soll, auch wenn die Anwendung geladen wird. Dies unterscheidet sich von MVP, wo Aktionen durch die Ansicht zum Präsentator geleitet werden. In MVC korreliert jede Aktion in der Ansicht mit einem Aufruf an einen Controller zusammen mit einer Aktion. Im Web beinhaltet jede Aktion einen Aufruf einer URL, auf deren anderer Seite ein Controller antwortet. Sobald der Controller die Verarbeitung abgeschlossen hat, wird die korrekte Ansicht zurückgegeben. Die Sequenz läuft auf diese Weise während der gesamten Lebensdauer der Anwendung weiter:

Aktion in der Ansicht
        -> Anruf an den Controller
        -> Steuerungslogik
        -> Controller gibt die Ansicht zurück.

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

Präsentationsmodell

Ein anderes zu betrachtendes Muster ist das Präsentationsmodell Muster. In diesem Muster gibt es keinen Presenter. Stattdessen bindet die Ansicht direkt an ein Präsentationsmodell. Das Präsentationsmodell ist ein speziell für die Ansicht erstelltes Modell. Dies bedeutet, dass dieses Modell Eigenschaften bereitstellen kann, die niemals einem Domänenmodell zugewiesen würden, da dies eine Verletzung der Problemtrennung darstellen würde. In diesem Fall bindet 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 offenlegen, 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 der PM das gesamte Verhalten für die Ansicht vollständig einkapselt. Dieses Muster ist ein sehr guter Kandidat für die Verwendung in WPF-Anwendungen und wird auch genannt Modell-Ansicht-AnsichtModell.

Da ist ein MSDN-Artikel zum Präsentationsmodell und ein Abschnitt in der Composite Application Guidance für WPF (ehemaliges Prisma) über Getrennte Präsentationsmuster


1796
2017-08-05 10:21



Ich habe vor einer Weile darüber gequotet und zitierte weiter Todd Snyders ausgezeichneter Beitrag über den Unterschied zwischen den beiden:

Hier sind die wichtigsten Unterschiede zwischen   die Muster:

MVP-Muster

  • View ist lockerer an das Modell gekoppelt. Der Moderator ist   verantwortlich für die Bindung an das Modell   die Aussicht.
  • Einfacher Komponententest, weil Interaktion mit der Ansicht durch ist   eine Schnittstelle
  • Normalerweise sehen Sie die Präsentationskarte eins zu eins. Komplexe Ansichten können haben   Multi-Moderatoren.

MVC-Muster

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

Es ist die beste Erklärung im Internet, die ich finden könnte.


384
2017-07-06 22:18



Dies ist eine zu starke Vereinfachung der vielen Varianten dieser Entwurfsmuster, aber so möchte ich über die Unterschiede zwischen den beiden denken.

MVC

MVC

MVP

enter image description here


367
2017-09-12 20:47



Hier sind Illustrationen, die den Kommunikationsfluss darstellen

enter image description here 

enter image description here


208
2017-08-25 21:22



MVP ist nicht ein Szenario, in dem die View zuständig ist (siehe z. B. Taligents MVP).
Ich finde es bedauerlich, dass die Leute dies immer noch als ein Muster (View in Charge) predigen, im Gegensatz zu einem Anti-Pattern, das widerspricht "Es ist nur eine Sichtweise" (Pragmatischer Programmierer). "Es ist nur eine Ansicht" besagt, dass die endgültige Ansicht, die dem Benutzer angezeigt wird, ein sekundäres Anliegen der Anwendung ist. Das MVP-Muster von Microsoft macht die Wiederverwendung von Ansichten viel schwieriger und schwieriger bequem entschuldigt den Designer von Microsoft, schlechte Praxis zu ermutigen.

Um ehrlich zu sein, denke ich, dass die grundlegenden Anliegen von MVC für jede MVP-Implementierung gelten und die Unterschiede fast vollständig semantisch sind. Solange Sie die Trennung von Bedenken zwischen der Ansicht (die die Daten anzeigt), der Steuerung (die die Benutzerinteraktion initialisiert und steuert) und dem Modell (den zugrunde liegenden Daten und / oder Diensten) verfolgen, profitieren Sie von den Vorteilen von MVC . Wenn Sie die Vorteile nutzen, wen interessiert es dann wirklich, ob Ihr Muster MVC, MVP oder Supervising Controller ist? Das einzige echt Muster bleibt als MVC, der Rest sind nur unterschiedliche Geschmacksrichtungen davon.

Erwägen Dies hochspannender Artikel, der eine Reihe dieser unterschiedlichen Implementierungen umfassend aufführt. Sie werden bemerken, dass sie alle im Grunde dasselbe tun, aber etwas anders.

Ich persönlich denke, MVP wurde erst vor kurzem als eingängiger Begriff wieder eingeführt, um entweder die Argumente zwischen semantischen Fanatikern zu reduzieren, die argumentieren, ob etwas wirklich MVC ist oder Microsoft Rapid Application Development Tools zu rechtfertigen. Keines dieser Gründe in meinen Büchern begründet seine Existenz als ein separates Designmuster.


148
2017-08-06 22:51



MVP: Die Ansicht ist verantwortlich.

Die Ansicht erzeugt in den meisten Fällen ihren Präsentator. Der Moderator interagiert mit dem Modell und manipuliert die Ansicht über eine Schnittstelle. Die Ansicht wird manchmal mit dem Moderator interagieren, normalerweise über eine Schnittstelle. Das kommt auf die Implementierung an; Möchten Sie, dass die Ansicht Methoden des Referenten aufruft, oder möchten Sie, dass die Ansicht Ereignisse enthält, auf die der Referent hört? Es läuft darauf hinaus: Die Ansicht kennt den Moderator. Die Ansicht delegiert an den Moderator.

MVC: Der Controller ist verantwortlich.

Der Controller wird basierend auf einem Ereignis / einer Anforderung erstellt oder aufgerufen. Der Controller erstellt dann die entsprechende Ansicht und interagiert mit dem Modell, um die Ansicht weiter zu konfigurieren. Es läuft darauf hinaus: Der Controller erstellt und verwaltet die Ansicht. Die Ansicht ist Slave für den Controller. Die Ansicht kennt den Controller nicht.


90
2017-12-20 02:10



enter image description here

MVC (Modellansicht-Controller)

Die Eingabe wird zuerst auf den Controller gerichtet, nicht auf die Ansicht. Diese Eingabe könnte von einem Benutzer kommen, der mit einer Seite interagiert, aber es könnte auch von einer einfachen Eingabe einer bestimmten URL in einen Browser stammen. In jedem Fall ist es ein Controller, der eine Verbindung zu einigen Funktionen hat. Zwischen dem Controller und der Ansicht besteht eine Viele-zu-Eins-Beziehung. Dies liegt daran, dass ein einzelner Controller basierend auf der ausgeführten Operation verschiedene Ansichten auswählen kann, die gerendert werden sollen. Beachten Sie den Einwegpfeil vom Controller zur Ansicht. Dies liegt daran, dass die View keine Kenntnisse über den Controller besitzt oder keinen Bezug zu diesem herstellt. Der Controller gibt das Modell zurück, so dass Wissen zwischen dem View und dem erwarteten Modell, das an es übergeben wird, vorhanden ist, aber nicht, dass der Controller es bedient.

MVP (Model View Presenter)

Die Eingabe beginnt mit der Ansicht, nicht mit dem Moderator. Es gibt eine Eins-zu-Eins-Zuordnung zwischen der Ansicht und dem zugeordneten Presenter. Die Ansicht enthält einen Verweis auf den Moderator. Der Präsentator reagiert auch auf Ereignisse, die von der Ansicht ausgelöst werden, und erkennt daher, dass die Ansicht damit verknüpft ist. Der Presenter aktualisiert die Ansicht basierend auf den angeforderten Aktionen, die er für das Modell ausführt, aber die Ansicht ist nicht Model aware.

Für mehr Referenz


62
2017-08-05 10:22



  • MVP = Model-View-Presenter
  • MVC = Model-View-Controller

    1. Beide Präsentationsmuster. Sie trennen die Abhängigkeiten zwischen einem Model (think Domain Objekte), Ihrem Bildschirm / Webseite (der View) und wie sich Ihre UI verhalten soll (Presenter / Controller)
    2. Sie sind ziemlich ähnlich im Konzept, Leute initialisieren den Presenter / Controller unterschiedlich je nach Geschmack.
    3. Ein toller Artikel über die Unterschiede ist Hier. Am bemerkenswertesten ist, dass das MVC-Muster das Modell hat, das die Ansicht aktualisiert.

31
2017-08-08 05:55



Es lohnt sich auch, daran zu erinnern, dass es auch verschiedene Arten von MVPs gibt. Fowler hat das Muster in zwei geteilt - Passive View und Supervising Controller.

Wenn Sie passive Ansicht verwenden, implementiert Ihre Ansicht normalerweise eine feinkörnige Schnittstelle mit Eigenschaften, die mehr oder weniger direkt auf das darunterliegende UI-Widget mappen. Zum Beispiel könnten Sie 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 "Passive View" genannt. Der Vorteil ist, dass die Ansicht einfach zu testen ist und es einfacher ist, zwischen UI-Plattformen (Web, Windows / XAML usw.) zu wechseln. Der Nachteil ist, dass Sie Dinge wie Datenbindung nicht nutzen können (was ist Ja wirklich mächtig in Frameworks wie WPF und Silverlight).

Die zweite Variante von MVP ist der Supervising Controller. In diesem Fall verfügt Ihre View möglicherweise über eine Eigenschaft namens Customer, die wiederum mit den UI-Widgets verbunden ist. Sie müssen nicht darüber nachdenken, die Ansicht zu synchronisieren und zu verwalten, und der Supervising Controller kann eingreifen und bei Bedarf helfen, z. B. mit komplexer Interaktionslogik.

Der dritte "Geschmack" von MVP (oder jemand würde es vielleicht ein separates Muster nennen) ist das Präsentationsmodell (oder manchmal als Model-View-ViewModel bezeichnet). Verglichen mit dem MVP "verschmelzen" Sie M und P zu einer Klasse. Sie haben Ihr Kundenobjekt, an das Ihre UI-Widgets gebunden sind, aber Sie haben auch zusätzliche UI-spezifische Felder wie "IsButtonEnabled" oder "IsReadOnly" usw.

Ich denke, die beste Ressource, die ich für die UI-Architektur gefunden habe, ist die Reihe von Blog-Posts, die von Jeremy Miller gemacht wurden Das Erstellen Ihrer eigenen CAB Series Table of Contents. Er hat alle Varianten von MVP abgedeckt und C # -Code gezeigt, um sie zu implementieren.

Ich habe auch über das Model-View-ViewModel-Muster im Kontext von Silverlight über at gebloggt YouCard Re-visited: Implementieren des ViewModel-Musters.


31
2018-04-06 13:51



Es gibt viele Antworten auf die Frage, aber ich hatte das Gefühl, dass eine wirklich einfache Antwort notwendig ist, die die beiden klar vergleicht. Hier ist die Diskussion, die ich gemacht habe, wenn ein Nutzer in einer MVP- und MVC-App nach einem Filmnamen sucht:

Benutzer: Klicken Sie auf klicken ...

Aussicht: Wer ist er? [MVP|MVC]

Benutzer: Ich habe gerade auf den Suchknopf geklickt ...

Aussicht: Ok, halt eine Sekunde .... [MVP|MVC]

( Aussicht anrufend Moderator|Regler ...) [MVP|MVC]

Aussicht: Hallo Moderator|Regler, ein Benutzer hat gerade auf den Suchknopf geklickt, was soll ich tun? [MVP|MVC]

Moderator|Regler: Hallo Aussicht, gibt es einen Suchbegriff auf dieser Seite? [MVP|MVC]

Aussicht: Ja, ... hier ist es ... "Klavier" [MVP|MVC]

Moderator: Vielen Dank Aussicht, ... in der Zwischenzeit suche ich den Suchbegriff auf der ModellBitte zeigen Sie ihm einen FortschrittsbalkenMVP|MVC]

( Moderator|Regler ruft das an Modell ...) [MVP|MVC]

Moderator|Regler: Hallo Modell, Haben Sie eine Übereinstimmung für diesen Suchbegriff ?: "piano" [MVP|MVC]

Modell: Hallo Moderator|Regler, Lass mich das überprüfen … [MVP|MVC]

( Modell macht eine Anfrage an die Filmdatenbank ...) [MVP|MVC]

( Nach einer Weile ... )

-------------- Hier beginnen MVP und MVC zu divergieren ---------------

Modell: Ich habe eine Liste für dich gefunden, Moderator, hier ist es in JSON "[{" name ":" Piano Teacher "," year ": 2001}, {" name ":" Piano "," year ": 1993}]" [MVP]

Modell: Es ist ein Ergebnis verfügbar, Regler. Ich habe eine Feldvariable in meiner Instanz erstellt und sie mit dem Ergebnis gefüllt. Sein Name ist "searchResultsList" [MVC]

(Moderator|Regler Vielen Dank Modell und kommt zurück zum Aussicht) [MVP|MVC]

Moderator: Danke für's Warten AussichtIch fand eine Liste passender Ergebnisse für Sie und arrangierte sie in einem vorzeigbaren Format: ["Piano Teacher 2001", "Piano 1993"]. Bitte zeigen Sie es dem Benutzer in einer vertikalen Liste. Verstecken Sie bitte auch den FortschrittsbalkenMVP]

Regler: Danke für's Warten Aussicht, Ich habe gefragt Modell über Ihre Suchanfrage. Es besagt, dass es eine Liste übereinstimmender Ergebnisse gefunden und in einer Variablen namens "searchResultsList" in seiner Instanz gespeichert hat. Sie können es von dort bekommen. Verstecken Sie bitte auch den FortschrittsbalkenMVC]

Aussicht: Vielen Dank Moderator [MVP]

Aussicht: Danke "Controller" [MVC] (Jetzt die Aussicht stellt sich selbst in Frage: Wie soll ich die Ergebnisse präsentieren, die ich von der Modell für den Benutzer? Sollte das Produktionsjahr des Films an erster oder letzter Stelle stehen ...? Sollte es in einer vertikalen oder horizontalen Liste sein? ...)

Falls Sie interessiert sind, habe ich eine Reihe von Artikeln geschrieben, die sich mit App-Architekturmustern (MVC, MVP, MVVP, saubere Architektur, ...) beschäftigen, begleitet von einem Github Repo Hier. Obwohl das Beispiel für Android geschrieben wurde, können die zugrunde liegenden Prinzipien auf jedes Medium angewendet werden.


17
2017-08-05 10:20