Was sind MVP und MVC und was ist der Unterschied?

24 answers
  • Model-View-Presenter

    In MVP enthält der Presenter die UI-Geschäftslogik für die View. Alle Aufrufe vom View-Delegierten direkt an den Presenter. Der Presenter ist auch direkt von der View entkoppelt und spricht mit ihm über eine Schnittstelle. Dies dient dazu, die Ansicht in einem Unit-Test zu verspotten. Ein gemeinsames Attribut von MVP ist, dass es viel bidirektionales Dispatching geben muss. Wenn beispielsweise jemand auf die Schaltfläche "Speichern" klickt, delegiert der Ereignishandler an die "OnSave" -Methode des Presenters. Nach dem Speichern ruft der Presenter die Ansicht über die Benutzeroberfläche zurück, sodass die Ansicht anzeigen kann, dass die Speicherung abgeschlossen ist.

    MVP ist in der Regel ein sehr natürliches Muster, um eine getrennte Darstellung in Web Forms zu erreichen. Der Grund ist, dass die View immer zuerst von der ASP.NET-Laufzeitumgebung erstellt wird. Sie können mehr über beide Varianten erfahren .

    Zwei Hauptvarianten

    Passive Ansicht: Die Ansicht ist so dumm wie möglich und enthält fast null Logik. Der Presenter ist ein mittlerer Mann, der mit der Ansicht und dem Modell spricht. Ansicht und Modell sind vollständig voneinander abgeschirmt. Das Modell kann Ereignisse auslösen, aber der Presenter abonniert sie für die Aktualisierung der Ansicht. In der passiven Ansicht gibt es keine direkte Datenbindung. Stattdessen werden in der Ansicht Setter-Eigenschaften angezeigt, die der Presenter zum Festlegen der Daten verwendet. Alle Status werden im Presenter und nicht in der Ansicht verwaltet.

    • Pro: Maximale Testbarkeitsoberfläche; Saubere Trennung von Ansicht und Modell
    • Con: Mehr Arbeit (zum Beispiel alle Setter-Eigenschaften), da Sie alle Daten selbst binden.

    Supervising Controller: Der Presenter behandelt Benutzergesten. Die Ansicht bindet sich direkt über die Datenbindung an das Modell. In diesem Fall ist es das GeschenkEr hat die Aufgabe, das Modell an die Ansicht weiterzugeben, damit es an es gebunden werden kann. Der Presenter enthält auch eine Logik für Gesten wie das Drücken einer Taste, die Navigation usw.

    • Pro: Durch die Nutzung von Datenbindungen wird die Menge an Code reduziert.
    • Con: Es gibt weniger zu testende Oberflächen (aufgrund der Datenbindung) und weniger Verkapselung in der Ansicht, da sie direkt mit dem Modell spricht.

    Model-View-Controller

    In der MVC ist der Controller dafür verantwortlich, zu bestimmen, welche View als Antwort angezeigt werden soll jede Aktion, auch wenn die Anwendung geladen wird. Dies unterscheidet sich von MVP, bei dem 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 sich ein Controller befindet, der antwortet. Sobald der Controller seine Verarbeitung abgeschlossen hat, wird die korrekte Ansicht zurückgegeben. Die Sequenz wird während der gesamten Dauer der Anwendung auf diese Weise fortgesetzt:

     Aktion in der Ansicht 
     - & gt; Aufruf an Controller 
     - & gt; Controller Logic 
     - & gt; Der Controller gibt die Ansicht zurück. 
     

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

    Präsentationsmodell

    Ein anderes Muster ist das Präsentationsmodell . In diesem Muster gibt es keinen Presenter. Stattdessen wird die Ansicht direkt an ein Präsentationsmodell gebunden. Das Präsentationsmodell ist ein speziell für die Ansicht erstelltes Modell. Das bedeutet, dass dieses Modell Eigenschaften verfügbar machen kann, die einem Domänenmodell niemals so zugeordnet würden

    04 December 2017
    11 revs, 9 users 57%Glenn Block
  • Ich habe vor einiger Zeit darüber gebloggt und unter Todd Snyders hervorragender Beitrag zum Unterschied zwischen den beiden :

    Hier sind die Hauptunterschiede zwischen den Mustern:

    MVP-Muster

    • Die Ansicht ist weniger an das Modell gekoppelt. Der Moderator ist für die Bindung des Modells an die Ansicht verantwortlich.
    • Einfachere Komponententests, da die Interaktion mit der Ansicht durch eine Schnittstelle
    • <| erfolgt >
    • Normalerweise zeigen Sie dem Moderator eine Karte an. Komplexe Ansichten enthalten möglicherweise Multi Presenter.

    MVC-Pattern

    • Controller basieren auf Verhaltensweisen und können in Ansichten
    • gemeinsam genutzt werden. Kann für die Festlegung der anzuzeigenden Ansicht verantwortlich sein
    • ul>

    Dies ist die beste Erklärung, die ich im Web finden kann.

    04 May 2015
    Peter Mortensen
  • Dies ist eine Vereinfachung der vielen Varianten dieser Entwurfsmuster, aber so möchte ich über die Unterschiede zwischen den beiden nachdenken.

    MVC

    Was sind MVP und MVC und was ist der Unterschied?

    MVP

    Was sind MVP und MVC und was ist der Unterschied?

    07 July 2013
    Phyxx
  • Hier sind Illustrationen, die den Kommunikationsfluss darstellen

    Was sind MVP und MVC und was ist der Unterschied?

    Was sind MVP und MVC und was ist der Unterschied?

    13 September 2014
    Ashraf Bashir
  • MVP ist nicht notwendigerweise ein Szenario, in dem die View zuständig ist (siehe beispielsweise Taligts MVP).
    Ich finde es bedauerlich, dass die Leute dies immer noch predigen als Muster (View in Charge) im Gegensatz zu einem Anti-Pattern, da es "Es ist nur eine Ansicht" (Pragmatic Programmer) widerspricht. "Es ist nur eine Ansicht" besagt, dass die endgültige Ansicht, die dem Benutzer angezeigt wird, ein zweitrangiges Anliegen der Anwendung ist. Microsofts MVP-Muster macht die Wiederverwendung von Views viel schwieriger und behebt bequem Microsofts Designer davon, schlechte Praktiken zu ermutigen.

    Grundlegende Bedenken von MVC gelten für jede MVP-Implementierung, und die Unterschiede sind fast vollständig semantisch. Solange Sie die Trennung der Bedenken zwischen der Ansicht (die die Daten anzeigt), dem Controller (der die Benutzerinteraktion initialisiert und steuert) und dem Modell (den zugrundeliegenden Daten und / oder Diensten) folgt, erreichen Sie die Vorteile von MVC . Wenn Sie die Vorteile nutzen, wen interessiert es dann wirklich, ob Sie MVC, MVP oder Supervising Controller verwenden? Das einzige echte -Muster bleibt als MVC, der Rest ist nur eine abweichende Variante.

    Betrachten Sie dieser äußerst spannende Artikel, der eine Reihe dieser unterschiedlichen Implementierungen auflistet. Sie können feststellen, dass sie im Grunde alle dasselbe machen, aber ein bisschen anders.

    Ich persönlich glaube, dass MVP erst kürzlich als einprägsamer Begriff für beide neu eingeführt wurde reduzieren Sie Argumente zwischen semantischen Bigotten, die argumentieren, ob etwas wirklich MVC ist oder nicht, oder um die Rapid Application Development-Tools von Microsofts zu rechtfertigen. Keiner dieser Gründe in meinen Büchern rechtfertigt seine Existenz als separates Entwurfsmuster.

    22 February 2013
    Quibblesome
  • MVP: Die Ansicht ist verantwortlich.

    Die Ansicht erstellt in den meisten Fällen ihren Präsentator. Der Präsentator interagiert mit dem Modell und bearbeitet die Ansicht über eine Schnittstelle. Die Ansicht interagiert manchmal mit dem Moderator, normalerweise über eine Schnittstelle. Dies hängt von der Implementierung ab. Möchten Sie, dass die Ansicht Methoden auf dem Präsentator aufruft, oder möchten Sie, dass in der Ansicht Ereignisse angezeigt werden, die der Präsentator hört? Es läuft darauf hinaus: Die Sicht weiß vom Moderator. Die Ansicht wird an den Moderator delegiert.

    MVC: Der Controller ist verantwortlich.

    Der Controller wird basierend auf einigen Elementen erstellt oder aufgerufen Veranstaltung / Anfrage. Der Controller erstellt dann die entsprechende Ansicht und interagiert mit dem Modell, um die Ansicht weiter zu konfigurieren. Es geht darum: Der Controller erstellt und verwaltet die Ansicht; Die Ansicht ist Slave der Steuerung. Die Ansicht kennt den Controller nicht.

    04 May 2015
    Peter Mortensen
  • Was sind MVP und MVC und was ist der Unterschied?

    MVC (Model View Controller)

    Der Eingang richtet sich zuerst an den Controller, nicht an die Ansicht. Diese Eingaben stammen möglicherweise von einem Benutzer, der mit einer Seite interagiert, aber auch, indem Sie einfach eine bestimmte URL in einen Browser eingeben. In beiden Fällen handelt es sich um einen Controller, an den eine Schnittstelle zum Starten einiger Funktionen angeschlossen ist. Zwischen Controller und View besteht eine Viele-zu-Eins-Beziehung. Dies liegt daran, dass ein einzelner Controller je nach ausgeführtem Vorgang möglicherweise unterschiedliche Ansichten zum Rendern auswählt. Beachten Sie den Einwegpfeil von Controller zu View. Dies liegt daran, dass die Ansicht keine Kenntnis von dem Controller hat oder darauf Bezug nimmt. Der Controller gibt das Modell zurück, daher gibt es Wissen zwischen der Ansicht und dem erwarteten Modell, das an sie übergeben wird, nicht jedoch über den Controller, der den Server bedient it up.

    MVP (Model View Presenter)

    Die Eingabe beginnt mit der Ansicht, nicht mit Der Presenter. Es gibt eine Eins-zu-Eins-Zuordnung zwischen der Ansicht und dem zugeordneten Presenter. Die Ansicht enthält einen Verweis auf den Presenter. Der Presenter reagiert auch auf Ereignisse, die von der View ausgelöst werden, sodass er sich der View, der er zugeordnet ist, bewusst wird. Der Presenter aktualisiert die View basierend auf den angeforderten Aktionen, die er für das Modell ausführt. Die View ist jedoch nicht modellabhängig.

    Weitere Referenz

    20 December 2015
    AVI
    • MVP = Modellansicht-Präsentator
    • MVC = Modellansicht-Controller

      < ol>
    • Beide Darstellungsmuster. Sie trennen die Abhängigkeiten zwischen einem Modell (think domain objects), Ihrem Bildschirm / Ihrer Webseite (der Ansicht) und dem Verhalten Ihrer Benutzeroberfläche (Presenter / Controller).
    • Sie sind sich ziemlich ähnlich Grundsätzlich initialisieren Leute den Presenter / Controller je nach Geschmack unterschiedlich.
    • Ein großartiger Artikel über die Unterschiede ist hier . Am bemerkenswertesten ist, dass das Modell im MVC-Muster die Ansicht aktualisiert.
    20 April 2013
    Andrii Nemchenko
  • Es ist auch erwähnenswert, dass es verschiedene Arten von MVPs gibt. Fowler hat das Muster in zwei Passive View- und Supervising-Controller aufgeteilt.

    Bei der Passivansicht implementiert Ihre Ansicht normalerweise eine feinkörnige Schnittstelle mit Eigenschaften, die mehr oder weniger direkt auf die UI-Widget unterlegen. Sie haben beispielsweise eine ICustomerView mit Eigenschaften wie Name und Adresse.

    Ihre Implementierung könnte in etwa wie folgt aussehen:

     [pre> 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 leicht zu testen ist und der Wechsel zwischen UI-Plattformen (Web, Windows / XAML usw.) einfacher ist. Der Nachteil ist, dass Sie Dinge wie Datenbindung (die wirklich wirklich mächtig ist in Frameworks wie WPF und Silverlight ).

    Die zweite Variante von MVP ist der Supervising Controller. In diesem Fall verfügt Ihre Ansicht möglicherweise über eine Eigenschaft mit dem Namen Customer, die wiederum mit den Widgets der Benutzeroberfläche verbunden wird. Sie müssen sich keine Gedanken über das Synchronisieren und Mikromanagement der Ansicht machen, und der Supervising Controller kann bei Bedarf eingreifen und Hilfe leisten, beispielsweise mit kompletter Interaktionslogik.

    Der dritte "Flavour" von MVP (oder jemand würde es vielleicht ein separates Muster nennen) ist das Präsentationsmodell (oder manchmal auch als Model-View-ViewModel bezeichnet). Verglichen mit dem MVP "verschmelzen" Sie das M und das P in eine Klasse. Sie haben Ihr Kundenobjekt, an das Ihre UI-Widgets Daten 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, sind die von Jeremy Miller ov erstellten Blogbeiträge

    04 May 2015
    Peter Mortensen
  • Es gibt viele Antworten auf die Frage, aber ich hatte das Bedürfnis nach einer wirklich einfachen Antwort, die beide klar miteinander vergleicht. Hier ist die Diskussion, die ich gemacht habe, wenn ein Benutzer in einer MVP- und MVC-App nach einem Filmnamen sucht:

    Benutzer: Klicken Sie auf…

    Ansicht : Wer ist das? [ MVP | MVC ]

    Benutzer: Ich habe nur auf die Suchschaltfläche geklickt ...

    Ansicht : Ok, warte eine Sekunde…. [ MVP | MVC ]

    ( Ansicht Aufruf des Presenters | Controller ...) [ MVP | MVC ]

    Ansicht em>: Hey Presenter | Controller , ein Benutzer hat gerade auf die Suchschaltfläche geklickt. Was soll ich tun? [ MVP | MVC ]

    Presenter | Controller : Hey View , gibt es auf dieser Seite einen Suchbegriff? [ MVP | MVC ]

    Ansicht : Ja,… hieres ist… „piano“ [ MVP | MVC ]

    Presenter : Vielen Dank Anzeigen ,… während ich den Suchbegriff im Modell nachsehe, zeigen Sie ihm / ihr einen Fortschrittsbalken [ MVP | MVC ]

    ( Presenter | Controller ruft das Model ...) auf. [ MVP | MVC ]

    Presenter | Controller : Hey Modell , haben Sie eine Übereinstimmung mit diesem Suchbegriff ?: "Klavier" [ MVP | MVC ]

    Modell : Hey Presenter | Controller , lassen Sie mich das überprüfen ... [ MVP | MVC ]

    ( Model fragt die Filmdatenbank ab ...) [ MVP | MVC ]

    (Nach einiger Zeit ...)

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

    Modell : Ich habe eine Liste für Sie gefunden, Presenter , hier ist es in JSON “[{" Name ":" Piano Teacher "," Year ": 2001}, {" Name ":" Piano "," Year ": 1993}]" [ MVP ]

    Modell : Es gibt Ergebnisse, Controller . Ich habe in meiner Instanz eine Feldvariable angelegt und mit dem Ergebnis gefüllt. Der Name lautet "searchResultsList" [ MVC ]

    ( Presenter | Controller Danke Modell und kehrt zur Ansicht ) [ MVP | MVC ]

    Presenter : Vielen Dank für das Warten von View . Ich habe eine Liste passender Ergebnisse für Sie gefunden und diese in einem vorzeigbaren Format dargestellt: ["Piano Teacher 2001", "Piano 1993 "]. Bitte zeigen Sie es dem Benutzer in einer vertikalen Liste. Bitte auch den Fortschrittsbalken jetzt ausblenden [ MVP ]

    Controller : Vielen Dank, dass Sie View warten , Ich habe Model nach Ihrer Suchanfrage gefragt. Es istays hat eine Liste passender Ergebnisse gefunden und diese in einer Variablen namens "searchResultsList" in seiner Instanz gespeichert. Sie können es von dort bekommen. Bitte auch den Fortschrittsbalken jetzt ausblenden [ MVC ]

    Ansicht : Vielen Dank Presenter [ MVP ]

    Ansicht : Vielen Dank "Controller" [ MVC ] (Nun fragt sich die View selbst: Wie kann ich dem Benutzer die Ergebnisse präsentieren, die ich vom Model erhalte? Sollte das Produktionsjahr des Films an erster Stelle oder an letzter Stelle stehen? Sollte es in einer vertikalen oder horizontalen Liste stehen? ...)

    Falls Sie interessiert sind, habe ich eine Reihe von Artikeln geschrieben, die sich mit App-Architekturmustern befassen (MVC, MVP, MVVP, saubere Architektur, ...) begleitet von einem Github-Repo hier . Obwohl das Beispiel für Android geschrieben wurde, können die zugrunde liegenden Prinzipien zutreffend sein

    06 April 2018
    Ali Nem