design patterns - Was sind MVP und MVC und was ist der Unterschied?

Translate

Beim Blick über das hinausRAD(Drag-Drop und Konfiguration) Methode zum Erstellen von Benutzeroberflächen, die von vielen Tools empfohlen werden. Es ist wahrscheinlich, dass Sie auf drei so genannte Entwurfsmuster stoßenModel View Controller, Model-View-PresenterundModel-View-ViewModel. Meine Frage besteht aus drei Teilen:

  1. Welche Probleme lösen diese Muster?
  2. Wie sind sie ähnlich?
  3. Wie unterscheiden sie sich?
This question and all comments follow the "Attribution Required."

Alle Antworten

Translate

Model-View-Presenter

ImMVPDer Presenter enthält die UI-Geschäftslogik für die Ansicht. Alle Aufrufe aus der Ansicht werden direkt an Presenter delegiert. Der Präsentator ist auch direkt von der Ansicht entkoppelt und kommuniziert mit ihm über eine Schnittstelle. Dies soll das Verspotten der Ansicht in einem Komponententest ermöglichen. Ein gemeinsames Merkmal von MVP ist, dass es viel Zwei-Wege-Versand geben muss. Wenn beispielsweise jemand auf die Schaltfläche "Speichern" klickt, delegiert der Ereignishandler an die "OnSave" -Methode des Präsentators. Sobald der Speichervorgang abgeschlossen ist, ruft der Präsentator die Ansicht über seine Benutzeroberfläche zurück, sodass in der Ansicht angezeigt werden kann, dass der Speichervorgang abgeschlossen wurde.

MVP ist in der Regel ein sehr natürliches Muster für die getrennte Darstellung in Web Forms. Der Grund dafür ist, dass die Ansicht immer zuerst von der ASP.NET-Laufzeit erstellt wird. Sie könnenErfahren Sie mehr über beide Varianten.

Zwei Hauptvarianten

Passive Ansicht:Die Ansicht ist so dumm wie möglich und enthält fast keine Logik. Der Moderator ist ein Mittelsmann, der mit der Ansicht und dem Modell 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 werden in der Ansicht Setter-Eigenschaften verfügbar gemacht, mit denen der Presenter die Daten festlegt. 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.

Überwachungscontroller:Der Präsentator verarbeitet Benutzergesten. Die Ansicht wird direkt über die Datenbindung an das Modell gebunden. In diesem Fall ist es Aufgabe des Präsentators, das Modell an die Ansicht weiterzugeben, damit es daran gebunden werden kann. Der Präsentator enthält auch Logik für Gesten wie Drücken einer Taste, Navigation usw.

  • Pro: Durch die Nutzung der Datenbindung wird die Codemenge reduziert.
  • Con: Es gibt weniger testbare Oberflächen (aufgrund der Datenbindung) und weniger Kapselung in der Ansicht, da sie direkt mit dem Modell kommuniziert.

Model View Controller

In demMVCDer Controller ist dafür verantwortlich, zu bestimmen, welche Ansicht als Reaktion auf eine Aktion angezeigt werden soll, auch wenn die Anwendung geladen wird. Dies unterscheidet sich von MVP, bei dem Aktionen über die Ansicht an den Präsentator weitergeleitet werden. In MVC korreliert jede Aktion in der Ansicht mit einem Aufruf eines Controllers zusammen mit einer Aktion. Im Web beinhaltet jede Aktion einen Aufruf einer URL, auf deren anderer Seite sich ein Controller befindet, der antwortet. Sobald dieser Controller seine Verarbeitung abgeschlossen hat, gibt er die richtige Ansicht zurück. Die Sequenz wird auf diese Weise während der gesamten Lebensdauer der Anwendung fortgesetzt:

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

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 die Ansicht normalerweise keine Logik im Code dahinter. Dies steht im Gegensatz zu MVP, wo dies unbedingt erforderlich ist, da die Ansicht niemals aufgerufen wird, wenn sie nicht an den Präsentator delegiert wird.

Präsentationsmodell

Ein weiteres Muster ist dasPräsentationsmodellMuster. In diesem Muster gibt es keinen Präsentator. Stattdessen wird die Ansicht direkt an ein Präsentationsmodell gebunden. Das Präsentationsmodell ist ein Modell, das speziell für die Ansicht erstellt wurde. Dies bedeutet, dass dieses Modell Eigenschaften verfügbar machen kann, die niemals einem Domänenmodell zugewiesen würden, da dies eine Verletzung der Trennung von Bedenken darstellen würde. In diesem Fall bindet das Präsentationsmodell an das Domänenmodell und kann Ereignisse abonnieren, die von diesem Modell stammen. Die Ansicht abonniert dann Ereignisse aus dem Präsentationsmodell und aktualisiert sich entsprechend. Das Präsentationsmodell kann Befehle verfügbar machen, die in der Ansicht zum Aufrufen von Aktionen verwendet werden. 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 kapselt. Dieses Muster ist ein sehr starker Kandidat für die Verwendung in WPF-Anwendungen und wird auch genanntModel-View-ViewModel.

Da ist einMSDN-Artikel zum Präsentationsmodellund ein Abschnitt in derComposite Application Guidance für WPF(ehemaliges Prisma) überGetrennte Präsentationsmuster

Quelle
Translate

Dies ist eine übermäßige Vereinfachung der vielen Varianten dieser Entwurfsmuster, aber so denke ich gerne über die Unterschiede zwischen den beiden nach.

MVC

MVC

MVP

enter image description here

Quelle
Translate

Ich habe vor einiger Zeit darüber gebloggt und zitiertTodd Snyders ausgezeichneter Beitrag zum Unterschied zwischen den beiden:

Hier sind die Hauptunterschiede zwischen den Mustern:

MVP-Muster

  • Die Ansicht ist lockerer an das Modell gekoppelt. Der Präsentator ist dafür verantwortlich, das Modell an die Ansicht zu binden.
  • Einfacher Unit-Test, da die Interaktion mit der Ansicht über eine Schnittstelle erfolgt
  • Normalerweise wird die Map des Präsentators eins zu eins angezeigt. Komplexe Ansichten können mehrere Präsentatoren haben.

MVC-Muster

  • Controller basieren auf Verhaltensweisen und können für mehrere Ansichten freigegeben werden
  • Kann dafür verantwortlich sein, zu bestimmen, welche Ansicht angezeigt werden soll

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

Quelle
Translate

Hier sind Abbildungen, die den Kommunikationsfluss darstellen

enter image description here

enter image description here

Quelle
Translate

MVP istnichtunbedingt ein Szenario, in dem die Ansicht zuständig ist (siehe zum Beispiel das MVP von Taligent).
Ich finde es bedauerlich, dass die Leute dies immer noch als Muster predigen (View in Charge), im Gegensatz zu einem Anti-Pattern, da es "Es ist nur eine Sichtweise" (Pragmatischer Programmierer) widerspricht. "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 erschwert die Wiederverwendung von Ansichten erheblichbequementschuldigt den Designer von Microsoft, schlechte Praktiken zu fördern.

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

ErwägendieseSehr spannender Artikel, der eine Reihe dieser unterschiedlichen Implementierungen umfassend auflistet. Sie können feststellen, dass sie alle im Grunde das Gleiche tun, aber etwas anders.

Ich persönlich denke, MVP wurde erst kürzlich als einprägsamer Begriff wieder eingeführt, um entweder Streitigkeiten zwischen semantischen Bigots zu reduzieren, die darüber streiten, ob etwas wirklich MVC ist oder nicht, oder um Microsoft Rapid Application Development-Tools zu rechtfertigen. Keiner dieser Gründe in meinen Büchern rechtfertigt seine Existenz als separates Entwurfsmuster.

Quelle
Translate

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 Präsentator, normalerweise über eine Schnittstelle. Dies hängt von der Umsetzung ab. Möchten Sie, dass die Ansicht Methoden für den Präsentator aufruft, oder möchten Sie, dass die Ansicht Ereignisse enthält, die der Präsentator abhört? Es läuft darauf hinaus: Die Ansicht kennt den Moderator. Die Ansicht wird an den Präsentator delegiert.

MVC: Der Controller ist verantwortlich.

Der Controller wird basierend auf einem Ereignis / einer Anforderung erstellt oder darauf zugegriffen. 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 der Steuerung. Die Ansicht kennt den Controller nicht.

Quelle
AVI
Translate

enter image description here

MVC (Model View Controller)

Die Eingabe richtet sich zuerst an den Controller, nicht an die Ansicht. Diese Eingabe kann von einem Benutzer stammen, der mit einer Seite interagiert, aber auch von der einfachen Eingabe einer bestimmten URL in einen Browser. In beiden Fällen handelt es sich um einen Controller, an den eine Schnittstelle angeschlossen ist, um einige Funktionen zu starten. Zwischen dem Controller und der Ansicht besteht eine Eins-zu-Eins-Beziehung. Dies liegt daran, dass ein einzelner Controller je nach ausgeführter Operation unterschiedliche Ansichten zum Rendern auswählen kann. Beachten Sie den Einwegpfeil vom Controller zur Ansicht. Dies liegt daran, dass die Ansicht keine Kenntnis von oder keinen Verweis auf den Controller hat. Der Controller gibt das Modell zurück, sodass zwischen der Ansicht und dem erwarteten Modell, das an das Modell übergeben wird, Kenntnisse bestehen, nicht jedoch zwischen dem Controller, der es bereitstellt.

MVP (Model View Presenter)

Die Eingabe beginnt mit der Ansicht, nicht mit dem Präsentator. Zwischen der Ansicht und dem zugehörigen Präsentator besteht eine Eins-zu-Eins-Zuordnung. Die Ansicht enthält einen Verweis auf den Präsentator. Der Präsentator reagiert auch auf Ereignisse, die von der Ansicht ausgelöst werden, sodass er die Ansicht kennt, mit der er verknüpft ist. Der Präsentator aktualisiert die Ansicht basierend auf den angeforderten Aktionen, die er für das Modell ausführt, aber die Ansicht ist nicht modellbewusst.

Für mehrReferenz

Quelle
Translate

Es gibt viele Antworten auf die Frage, aber ich hatte das Gefühl, dass eine wirklich einfache Antwort erforderlich ist, um die beiden klar zu vergleichen. Hier ist die Diskussion, die ich erfunden habe, als ein Benutzer in einer MVP- und MVC-App nach einem Filmnamen sucht:

Benutzer: Klicken Sie auf ...

Aussicht: Wer ist er? [MVP|MVC]

Benutzer: Ich habe gerade auf die Suchschaltfläche geklickt…

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

( AussichtAufruf derModerator|Regler…) [MVP|MVC]

Aussicht: HalloModerator|Regler, ein Benutzer hat gerade auf die Suchschaltfläche geklickt, was soll ich tun? [MVP|MVC]

Moderator|Regler: HalloAussichtGibt es einen Suchbegriff auf dieser Seite? [MVP|MVC]

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

Moderator: Vielen DankAussicht,… In der Zwischenzeit suche ich den Suchbegriff auf derModell, bitte zeigen Sie ihm / ihr einen Fortschrittsbalken [MVP|MVC]

( Moderator|Reglerruft dieModell…) [MVP|MVC]

Moderator|Regler: HalloModell, Haben Sie eine Übereinstimmung mit diesem Suchbegriff?: "Klavier" [MVP|MVC]

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

( Modellstellt eine Abfrage 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 ":" Klavierlehrer "," Jahr ": 2001}, {" Name ":" Klavier "," Jahr ": 1993}]" [MVP]

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

(Moderator|ReglerVielen DankModellund kommt zurück zumAussicht) [MVP|MVC]

Moderator: Danke für's WartenAussichtIch habe eine Liste mit passenden Ergebnissen für Sie gefunden und sie in einem vorzeigbaren Format angeordnet: ["Piano Teacher 2001", "Piano 1993"]. Bitte zeigen Sie es dem Benutzer in einer vertikalen Liste. Bitte verstecken Sie jetzt auch den Fortschrittsbalken [MVP]

Regler: Danke für's WartenAussicht, Ich habe gefragtModellüber Ihre Suchanfrage. Es heißt, es habe eine Liste übereinstimmender Ergebnisse gefunden und diese in einer Variablen namens "searchResultsList" in seiner Instanz gespeichert. Sie können es von dort bekommen. Bitte verstecken Sie jetzt auch den Fortschrittsbalken [MVC]

Aussicht: Vielen DankModerator [MVP]

Aussicht: Danke "Controller" [MVC] (Jetzt dieAussichtstellt sich die Frage: Wie soll ich die Ergebnisse präsentieren, die ich aus demModellan 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, ...) befassen, begleitet von einem Github-RepoHier. Obwohl das Beispiel für Android geschrieben wurde, können die zugrunde liegenden Prinzipien auf jedes Medium angewendet werden.

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

    1. Beide Präsentationsmuster. Sie trennen die Abhängigkeiten zwischen einem Modell (denken Sie an Domänenobjekte), Ihrem Bildschirm / Ihrer Webseite (der Ansicht) und dem Verhalten Ihrer Benutzeroberfläche (Presenter / Controller).
    2. Das Konzept ist ziemlich ähnlich. Die Leute initialisieren den Presenter / Controller je nach Geschmack unterschiedlich.
    3. Ein großartiger Artikel über die Unterschiede istHier. Am bemerkenswertesten ist, dass das Modell im MVC-Muster die Ansicht aktualisiert.
Quelle
Translate

Denken Sie auch daran, dass es auch verschiedene Arten von MVPs gibt. Fowler hat das Muster in zwei Teile geteilt - Passive View und Supervising Controller.

Wenn Sie die passive Ansicht verwenden, implementiert Ihre Ansicht normalerweise eine feinkörnige Oberfläche mit Eigenschaften, die mehr oder weniger direkt dem zugrunde liegenden UI-Widget zugeordnet sind. Beispielsweise haben Sie möglicherweise eine ICustomerView mit Eigenschaften wie Name und Adresse.

Ihre Implementierung könnte ungefähr so aussehen:

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

Ihre Presenter-Klasse spricht mit dem Modell und "ordnet" es der Ansicht zu. Dieser Ansatz wird als "Passive Ansicht" bezeichnet. Der Vorteil besteht darin, dass die Ansicht einfach zu testen ist und sich leichter zwischen UI-Plattformen (Web, Windows / XAML usw.) bewegen lässt. Der Nachteil ist, dass Sie Dinge wie die Datenbindung nicht nutzen könnenJa wirklichmächtig in Frameworks wieWPFundSilverlight).

Die zweite Variante von MVP ist der Supervising Controller. In diesem Fall verfügt Ihre Ansicht möglicherweise über eine Eigenschaft namens "Kunde", die dann wiederum an die UI-Widgets gebunden ist. Sie müssen nicht über das Synchronisieren und Verwalten der Ansicht nachdenken, und der Supervising Controller kann bei Bedarf eingreifen und helfen, beispielsweise bei vollständiger Interaktionslogik.

Die dritte "Variante" von MVP (oder jemand würde es vielleicht ein separates Muster nennen) ist das Präsentationsmodell (oder manchmal auch als Model-View-ViewModel bezeichnet). Im Vergleich zum MVP "verschmelzen" Sie das M und das P zu 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 für die UI-Architektur gefunden habe, ist die Reihe von Blog-Posts, die Jeremy Miller bei verfasst hatDas Inhaltsverzeichnis der Build Your Own CAB Series. Er deckte alle Varianten von MVP ab und zeigte C # -Code, um sie zu implementieren.

Ich habe auch über das Model-View-ViewModel-Muster im Kontext von Silverlight bei at gebloggtYouCard erneut besucht: Implementieren des ViewModel-Musters.

Quelle
Translate

Model View Controller

MVCist ein Muster für die Architektur einer Softwareanwendung. Es unterteilt die Anwendungslogik in drei separate Teile und fördert so die Modularität sowie die einfache Zusammenarbeit und Wiederverwendung. Es macht Anwendungen auch flexibler und begrüßt Iterationen. Es unterteilt eine Anwendung in die folgenden Komponenten:

  • Modellefür den Umgang mit Daten und Geschäftslogik
  • Controllerzur Handhabung der Benutzeroberfläche und Anwendung
  • Ansichtenzur Handhabung von Objekten und Präsentationen der grafischen Benutzeroberfläche

Um dies etwas klarer zu machen, stellen wir uns eine einfache Einkaufslisten-App vor. Wir wollen nur eine Liste mit Namen, Menge und Preis jedes Artikels, den wir diese Woche kaufen müssen. Im Folgenden wird beschrieben, wie wir einige dieser Funktionen mit MVC implementieren können.

enter image description here

Model-View-Presenter

  • DasModell-sind die Daten, die in der Ansicht (Benutzeroberfläche) angezeigt werden.
  • DasAussichtist eine Schnittstelle, die Daten (das Modell) anzeigt und Benutzerbefehle (Ereignisse) an den Präsentator weiterleitet, um auf diese Daten zu reagieren. Die Ansicht enthält normalerweise einen Verweis auf ihren Präsentator.
  • DasModeratorist der „Middle-Man“ (vom Controller in MVC gespielt) und bezieht sich sowohl auf die Ansicht als auch auf das Modell.Bitte beachten Sie, dass das Wort "Modell"ist irreführend. Es sollte eher seinGeschäftslogik, die ein Modell abruft oder manipuliert. Beispiel: Wenn Sie eine Datenbank haben, in der Benutzer in einer Datenbanktabelle gespeichert sind und Ihre Ansicht eine Liste von Benutzern anzeigen möchte, hat der Präsentator einen Verweis auf Ihre Datenbankgeschäftslogik (wie ein DAO), von dem aus der Präsentator eine Liste abfragt von Benutzern.

Wenn Sie ein Beispiel mit einfacher Implementierung sehen möchten, überprüfen Sie bittedieseGitHub-Beitrag

Ein konkreter Workflow zum Abfragen und Anzeigen einer Liste von Benutzern aus einer Datenbank könnte folgendermaßen funktionieren:enter image description here

Was ist derUnterschiedzwischenMVCundMVPMuster?

MVC-Muster

  • Controller basieren auf Verhaltensweisen und können für mehrere Ansichten freigegeben werden

  • Kann für die Bestimmung der anzuzeigenden Ansicht verantwortlich sein (Front Controller Pattern)

MVP-Muster

  • Die Ansicht ist lockerer an das Modell gekoppelt. Der Präsentator ist dafür verantwortlich, das Modell an die Ansicht zu binden.

  • Einfacher Unit-Test, da die Interaktion mit der Ansicht über eine Schnittstelle erfolgt

  • Normalerweise wird die Map des Präsentators eins zu eins angezeigt. Komplexe Ansichten können mehrere Präsentatoren haben.

Quelle
Translate

Sie befassen sich jeweils mit unterschiedlichen Problemen und können sogar miteinander kombiniert werden, um so etwas wie das Folgende zu erhalten

The Combined Pattern

Es gibt auchEin vollständiger Vergleich von MVC, MVP und MVVM hier

Quelle
Translate

Beide Frameworks zielen darauf ab, Probleme zu trennen - beispielsweise die Interaktion mit einer Datenquelle (Modell), Anwendungslogik (oder die Umwandlung dieser Daten in nützliche Informationen) (Controller / Presenter) und Anzeigecode (Ansicht). In einigen Fällen kann das Modell auch verwendet werden, um eine Datenquelle in eine übergeordnete Abstraktion umzuwandeln. Ein gutes Beispiel dafür ist dasMVC Storefront-Projekt.

Es gibt eine DiskussionHierin Bezug auf 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, jedoch nicht miteinander.

Bei MVP-Designs kann der Präsentator auf das Modell zugreifen und mit der Ansicht interagieren.

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

Schauen Sie sich das an, um sich vielleicht ein Bild von der Unterscheidung zwischen ASP.NET MVC und MVP zu machendiese MIX Präsentationvon Scott Hanselman.

Quelle
Translate

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

In der Architektur ist MVP ein Page Controller-basierter Ansatz, während MVC ein Front Controller-basierter Ansatz ist. Dies bedeutet, dass der Lebenszyklus von Seiten im MVP-Standardwebformular nur durch Extrahieren der Geschäftslogik aus dem dahinter liegenden Code verbessert wird. Mit anderen Worten, die Seite ist diejenige, die die http-Anforderung bearbeitet. Mit anderen Worten, MVP IMHO ist eine evolutionäre Art der Verbesserung von Webformularen. MVC hingegen ändert das Spiel vollständig, da die Anforderung von der Controller-Klasse abgefangen wird, bevor die Seite geladen wird, die Geschäftslogik dort ausgeführt wird und am Ende der Controller-Verarbeitung die gerade auf die Seite gespeicherten Daten verarbeitet werden ("Ansicht") Sinn, MVC sieht (zumindest für mich) sehr nach Supervising Controller aus, das mit der Routing-Engine erweitert wurde

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

Die Entscheidung, wie einer von ihnen ausgewählt werden soll, sollte meiner Meinung nach davon abhängen, wie viel Zeit man in die Webentwicklung vom Typ ASP NET Web Form investiert hat. Wenn man sich in Webformularen als gut betrachten würde, würde ich MVP vorschlagen. Wenn man sich in Dingen wie dem Seitenlebenszyklus usw. nicht so wohl fühlt, könnte MVC ein Weg sein, hierher zu kommen.

Hier ist noch ein Blog-Link, der ein bisschen 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

Quelle
Translate

Ich habe sowohl MVP als auch MVC verwendet, und obwohl wir als Entwickler dazu neigen, uns auf die technischen Unterschiede beider Muster zu konzentrieren, hängt der Punkt für MVP in IMHO viel mehr mit der einfachen Übernahme zusammen als mit irgendetwas anderem.

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

Meine Erfahrung zeigt mir, dass es relativ einfach ist, ein Team von Webformularen zu MVP und dann von MVP zu MVC zu wechseln. Der Wechsel von Webformularen zu 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

Quelle
Translate

In MVP zeichnet die Ansicht Daten vom Präsentator, der Daten aus dem Modell zeichnet und vorbereitet / normalisiert, während in MVC die Steuerung Daten aus dem Modell zeichnet und durch Drücken in die Ansicht einstellt.

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

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

In diesen Frameworks weiß die UI / HTML5 / XAML, welche Eigenschaft des Präsentators jedes UI-Element anzeigt. Wenn Sie also eine Ansicht an einen Präsentator binden, sucht die Ansicht nach den Eigenschaften und weiß, wie und wie Daten daraus gezogen werden um sie festzulegen, wenn der Benutzer einen Wert in der Benutzeroberfläche ändert.

Wenn das Modell beispielsweise ein Auto ist, ist der Präsentator eine Art Automoderator, der die Eigenschaften des Autos (Jahr, Hersteller, Sitze usw.) der Ansicht aussetzt. Die Ansicht weiß, dass das Textfeld "Autohersteller" die Eigenschaft "Moderator-Hersteller" anzeigen muss.

Sie können dann viele verschiedene Arten von Präsentatoren an die Ansicht binden. Alle müssen über die Maker-Eigenschaft verfügen. Es kann sich um ein Flugzeug, einen Zug oder was auch immer handeln, die Ansicht ist egal. Die Ansicht bezieht Daten vom Präsentator - egal welche -, solange sie eine vereinbarte Schnittstelle implementiert.

Wenn Sie dieses Bindungsframework entfernen, ist es tatsächlich der Controller :-)

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

MVC ist großartig, aber das Problem ist, dass normalerweise der Controller pro Ansicht angezeigt wird. Controller A weiß, wie Felder in Ansicht A festgelegt werden. Wenn Sie nun möchten, dass Ansicht A Daten von Modell B anzeigt, muss Controller A Modell B kennen oder Controller A muss ein Objekt mit einer Schnittstelle empfangen MVP nur ohne die Bindungen, oder Sie müssen den UI-Set-Code in Controller B neu schreiben.

Schlussfolgerung - MVP und MVC sind beide entkoppelt von UI-Mustern, aber MVP verwendet normalerweise ein Bindungsframework, das MVC darunter ist. DIESES MVP befindet sich auf einer höheren architektonischen Ebene als MVC und ein Wrapper-Muster über MVC.

Quelle
Translate

Meine bescheidene kurze Sichtweise: MVP ist für große Maßstäbe und MVC für kleine Maßstäbe. Bei MVC habe ich manchmal das Gefühl, dass V und C zwei Seiten einer einzelnen unteilbaren Komponente sind, die eher direkt an M gebunden ist, und eine fällt unweigerlich darauf, wenn man auf kürzere Maßstäbe wie UI-Steuerelemente und Basis-Widgets zurückgreift. Bei dieser Granularität macht MVP wenig Sinn. Wenn man im Gegenteil zu größeren Maßstäben übergeht, wird die richtige Schnittstelle wichtiger, ebenso wie die eindeutige Zuweisung von Verantwortlichkeiten, und hier kommt MVP.

Auf der anderen Seite kann diese Skalierungsregel eines Daumens sehr wenig Gewicht haben, wenn die Plattformmerkmale eine Art von Beziehung zwischen den Komponenten begünstigen, wie zum Beispiel im Web, wo es einfacher zu sein scheint, MVC zu implementieren als MVP.

Quelle
Translate

Es gibt viele Versionen von MVC. Diese Antwort bezieht sich auf die ursprüngliche MVC in Smalltalk. Kurz gesagt, es istimage of mvc vs mvp

Dieses Gesprächdroidcon NYC 2017 - Sauberes App-Design mit Architekturkomponentenklärt es

enter image description here enter image description here

Quelle
Translate

Es gibtdieseschönes Video von Onkel Bob, in dem er MVC & MVP am Ende kurz erklärt.

IMO, MVP ist eine verbesserte Version von MVC, bei der Sie die Bedenken hinsichtlich der Anzeige (der Daten) von der Darstellung der Ansicht (der Ansicht) grundsätzlich trennen. Presenter enthält ein bisschen die Geschäftslogik Ihrer Benutzeroberfläche, legt implizit fest, welche Daten präsentiert werden sollen, und gibt Ihnen eine Liste von dummen Ansichtsmodellen. Und wenn es an der Zeit ist, die Daten anzuzeigen, schließen Sie einfach Ihre Ansicht (wahrscheinlich mit denselben IDs) an Ihren Adapter an und legen die relevanten Ansichtsfelder mithilfe dieser Ansichtsmodelle fest, wobei eine minimale Menge an Code eingeführt wird (nur mithilfe von Setzern). Der Hauptvorteil besteht darin, dass Sie Ihre UI-Geschäftslogik anhand vieler / verschiedener Ansichten testen können, z. B. anhand von Elementen in einer horizontalen oder vertikalen Liste.

In MVC sprechen wir über Schnittstellen (Grenzen), um verschiedene Schichten zu verkleben. Controller ist ein Plug-In für unsere Architektur, aber es gibt keine solche Einschränkung, um aufzuerlegen, was angezeigt werden soll. In diesem Sinne ist MVP eine Art MVC mit dem Konzept, dass Ansichten über Adapter an den Controller angeschlossen werden können.

Hoffe das hilft besser.

Quelle
Translate

Die einfachste Antwort ist, wie die Ansicht mit dem Modell interagiert. In MVP ist die Ansicht an den Präsentator gebunden, der als Vermittler zwischen der Ansicht und dem Modell fungiert, Eingaben aus der Ansicht übernimmt, Daten aus dem Modell abruft, dann eine Geschäftslogik ausführt und schließlich die Ansicht aktualisiert. In MVC aktualisiert das Modell die Ansicht direkt, anstatt über den Controller zurückzukehren.

Quelle
Translate

Ich denke dieses Bild von Erwin Vandervalk (und dem dazugehörigenArtikel) ist die beste Erklärung für MVC, MVP und MVVM, ihre Ähnlichkeiten und ihre Unterschiede. DasArtikelwird in Suchmaschinenergebnissen für Abfragen zu "MVC, MVP und MVVM" nicht angezeigt, da der Titel des Artikels nicht die Wörter "MVC" und "MVP" enthält. aber es ist die beste Erklärung, denke ich.

image explaining MVC, MVP and MVVM - by Erwin Vandervalk

(DasArtikelstimmt auch mit dem überein, was Onkel Bob Martin in einem seiner Vorträge gesagt hat: MVC wurde ursprünglich für die kleinen UI-Komponenten entwickelt, nicht für die Architektur des Systems.

Quelle
Translate
  • In MVC hat View den UI-Teil, Controller ist der Vermittler zwischen View und Model & Model enthält die Geschäftslogik.
  • In MVP enthält View sowohl die Benutzeroberfläche als auch die Implementierung des Präsentators, da hier der Präsentator nur eine Schnittstelle ist und das Modell dasselbe ist, dh Geschäftslogik enthält.
Quelle
Translate

MVP

MVP steht für Model - View-Presenter. Dies wurde Anfang 2007 deutlich, als Microsoft Smart Client-Windows-Anwendungen einführte.

Presenter fungiert als Aufsichtsfunktion in MVP, die View-Ereignisse und Geschäftslogiken von Modellen bindet.

Die Ansichtsereignisbindung wird in Presenter über eine Ansichtsoberfläche implementiert.

View ist der Initiator für Benutzereingaben und delegiert die Ereignisse an Presenter. Presenter verarbeitet Ereignisbindungen und ruft Daten von Modellen ab.

Vorteile:View hat nur eine Benutzeroberfläche, keine Logik. Hohe Testbarkeit

Nachteile:Etwas komplexer und aufwändiger beim Implementieren von Ereignisbindungen

MVC

MVC steht für Model-View-Controller. Der Controller ist für das Erstellen von Modellen und das Rendern von Ansichten mit Bindungsmodellen verantwortlich.

Der Controller ist der Initiator und entscheidet, welche Ansicht gerendert werden soll.

Vorteile:Schwerpunkt auf dem Prinzip der Einzelverantwortung Hohe Testbarkeit

Nachteile:Manchmal zu viel Arbeitsaufwand für Controller, wenn Sie versuchen, mehrere Ansichten in demselben Controller zu rendern.

Quelle