Was sind MVP und MVC und was ist der Unterschied?

StackOverflow https://stackoverflow.com/questions/2056

Frage

Beim Blick über den Tellerrand hinaus RAD (Drag-Drop und Konfigurieren) Methode zum Erstellen von Benutzeroberflächen, die von vielen Tools empfohlen wird, werden Sie wahrscheinlich auf drei sogenannte Entwurfsmuster stoßen Model View Controller, Model-View-Presenter Und Model-View-ViewModel.Meine Frage besteht aus drei Teilen:

  1. Welche Probleme lösen diese Muster?
  2. Wie ähneln sie sich?
  3. Wie unterscheiden sie sich?
War es hilfreich?

Lösung

Model-View-Presenter

In MVP, enthält der Presenter die UI-Geschäftslogik für die Ansicht.Alle Aufrufe vom View-Delegaten direkt an Presenter.Der Presenter ist außerdem direkt von der View entkoppelt und kommuniziert mit dieser über eine Schnittstelle.Dies soll das Verspotten der Ansicht in einem Komponententest ermöglichen.Ein gemeinsames Merkmal von MVP ist, dass es viele bidirektionale Dispatchings geben muss.Wenn beispielsweise jemand auf die Schaltfläche „Speichern“ klickt, delegiert der Ereignishandler an die Methode „OnSave“ des Presenters.Sobald die Speicherung abgeschlossen ist, ruft der Präsentator die Ansicht über seine Schnittstelle 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 Webformularen zu erreichen.Der Grund dafür ist, dass die Ansicht immer zuerst von der ASP.NET-Laufzeit erstellt wird.Du kannst Erfahren Sie mehr über beide Varianten.

Zwei Hauptvarianten

Passive Ansicht: Die Ansicht ist so dumm wie möglich und enthält nahezu keine Logik.Der Moderator ist ein Mittelsmann, der mit der Ansicht und dem Modell spricht.Ansicht und 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 bereit, die der Presenter zum Festlegen der Daten verwendet.Der gesamte Status wird im Presenter und nicht in der Ansicht verwaltet.

  • Profi:maximale Testbarkeitsoberfläche;saubere Trennung von Ansicht und Modell
  • Nachteil:mehr Arbeit (z. B. alle Setter-Eigenschaften), da Sie die gesamte Datenbindung selbst durchführen.

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

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

Model View Controller

Im MVC, ist der Controller dafür verantwortlich, zu bestimmen, welche Ansicht als Reaktion auf jede Aktion angezeigt werden soll, auch wenn die Anwendung geladen wird.Dies unterscheidet sich von MVP, wo Aktionen über die Ansicht an den Präsentator weitergeleitet 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 dieser Controller seine Verarbeitung abgeschlossen hat, gibt er die richtige Ansicht zurück.Die Abfolge wird während der gesamten Lebensdauer der Anwendung auf diese Weise 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 verfügt die Ansicht normalerweise über keine Logik im Code dahinter.Dies steht im Gegensatz zu MVP, wo es absolut notwendig ist, denn wenn die Ansicht nicht an den Präsentator delegiert, wird sie nie aufgerufen.

Präsentationsmodell

Ein weiteres zu betrachtendes Muster ist das Präsentationsmodell Muster.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 offenlegen kann, die man niemals einem Domänenmodell zuordnen würde, da dies einen Verstoß gegen die Interessentrennung 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, die vom Präsentationsmodell kommen, und aktualisiert sich entsprechend.Das Präsentationsmodell kann Befehle verfügbar machen, die die Ansicht zum Aufrufen von Aktionen verwendet.Der Vorteil dieses Ansatzes besteht darin, dass Sie den Code-Behind praktisch vollständig entfernen können, da der PM das gesamte Verhalten für die Ansicht vollständig kapselt.Dieses Muster ist ein sehr guter Kandidat für die Verwendung in WPF-Anwendungen und wird auch aufgerufen Model-View-ViewModel.

Da ist ein MSDN-Artikel über das Präsentationsmodell und ein Abschnitt in der Leitfaden für zusammengesetzte Anwendungen für WPF (ehemaliges Prisma) ungefähr Getrennte Präsentationsmuster

Andere Tipps

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

Ich habe vor einiger Zeit darüber gebloggt und dabei zitiert Todd Snyders hervorragender Beitrag zum Unterschied zwischen den beiden:

Hier sind die wichtigsten Unterschiede 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.
  • Einfacher zu Unit -Test, da die Interaktion mit der Ansicht über eine Schnittstelle erfolgt
  • Normalerweise wird die Karte eins zu eins angezeigt.Komplexe Ansichten können Multi -Moderatoren haben.

MVC-Muster

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

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

Hier finden Sie Abbildungen, die den Kommunikationsfluss darstellen

enter image description here

enter image description here

MVP ist nicht notwendigerweise ein Szenario, in dem die Ansicht verantwortlich ist (siehe zum Beispiel Taligents MVP).
Ich finde es bedauerlich, dass die Leute dies immer noch als Muster (View in Charge) und nicht als Anti-Pattern predigen, da es im Widerspruch zu „Es ist nur eine Ansicht“ (Pragmatic Programmer) steht.„Es ist nur eine Ansicht“ besagt, dass die endgültige Ansicht, die dem Benutzer angezeigt wird, ein zweitrangiges Anliegen der Anwendung ist.Das MVP-Muster von Microsoft macht die Wiederverwendung von Ansichten viel schwieriger und bequem entschuldigt den Microsoft-Designer davon, 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 semantischer Natur sind.Solange Sie die Interessenstrennung 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) befolgen, 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?Die einzige real Das Muster bleibt MVC, der Rest sind nur unterschiedliche Varianten davon.

In Betracht ziehen Das höchst spannender Artikel, der eine Reihe dieser unterschiedlichen Umsetzungen umfassend auflistet.Sie werden vielleicht bemerken, dass sie im Grunde alle das Gleiche tun, aber etwas anders.

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

MVP:Die Aussicht hat das Sagen.

Die Ansicht erstellt in den meisten Fällen ihren Präsentator.Der Präsentator interagiert mit dem Modell und manipuliert die Ansicht über eine Schnittstelle.Die Ansicht interagiert manchmal mit dem Präsentator, normalerweise über eine Schnittstelle.Es kommt auf die Umsetzung an;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 auf ihn 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 des Controllers.Die Ansicht kennt den Controller nicht.

enter image description here

MVC (Model View Controller)

Die Eingabe wird zuerst an den Controller gerichtet, nicht an die Ansicht.Diese Eingabe kann von einem Benutzer stammen, der mit einer Seite interagiert, sie könnte aber auch einfach durch die Eingabe einer bestimmten URL in einen Browser erfolgen.In beiden Fällen handelt es sich um einen Controller, der mit dem Controller verbunden ist, um einige Funktionen auszulösen.Zwischen dem Controller und der Ansicht besteht eine Viele-zu-Eins-Beziehung.Dies liegt daran, dass ein einzelner Controller basierend auf dem ausgeführten Vorgang möglicherweise unterschiedliche Ansichten zum Rendern auswählt.Beachten Sie den Einwegpfeil vom Controller zur Ansicht.Dies liegt daran, dass die Ansicht keine Kenntnis vom Controller oder keinen Verweis darauf hat.Der Controller gibt das Modell zurück, es besteht also Wissen zwischen der Ansicht und dem erwarteten Modell, das an ihn übergeben wird, aber nicht der Controller, der es bereitstellt.

MVP (Model View Presenter)

Die Eingabe beginnt mit der Ansicht, nicht mit dem Präsentator.Es gibt eine Eins-zu-eins-Zuordnung zwischen der Ansicht und dem zugehörigen Präsentator.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 weiß, mit welcher Ansicht er verknüpft ist.Der Präsentator aktualisiert die Ansicht basierend auf den angeforderten Aktionen, die er am Modell ausführt, aber die Ansicht ist nicht modellbewusst.

Für mehr Referenz

Es gibt viele Antworten auf die Frage, aber ich hatte das Gefühl, dass es einer wirklich einfachen Antwort bedarf, die die beiden klar vergleicht.Hier ist die Diskussion, die ich mir ausgedacht habe, als ein Benutzer in einer MVP- und MVC-App nach einem Filmnamen sucht:

Benutzer:Klick klick …

Sicht:Wer ist er?[MVP|MVC]

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

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

( Sicht Aufruf der Moderator|Regler … ) [MVP|MVC]

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

Moderator|Regler:Hey Sicht, Gibt es auf dieser Seite einen Suchbegriff?[MVP|MVC]

Sicht:Ja, ... hier ist es ... „Klavier“ [MVP|MVC]

Moderator:Danke Sicht,… Währenddessen suche ich den Suchbegriff auf der Modell, zeigen Sie ihm/ihr bitte einen Fortschrittsbalken [MVP|MVC]

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

Moderator|Regler:Hey Modell, Gibt es eine Übereinstimmung für diesen Suchbegriff?:„Klavier“ [MVP|MVC]

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

( Modell stellt eine Abfrage an die Filmdatenbank … ) [MVP|MVC]

( Nach einer Weile ...)

-------------- Hier beginnen MVP und MVC auseinander zu laufen ---------------

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 liegen einige Ergebnisse vor, Regler.Ich habe in meiner Instanz eine Feldvariable erstellt und diese mit dem Ergebnis gefüllt.Der Name lautet „searchResultsList“ [MVC]

(Moderator|Regler Danke Modell und kommt zurück zum Sicht) [MVP|MVC]

Moderator:Danke für's Warten Sicht, ich habe eine Liste mit passenden Ergebnissen für Sie gefunden und diese in einem ansehnlichen Format zusammengestellt:[„Klavierlehrer 2001“, „Klavier 1993“].Bitte zeigen Sie es dem Benutzer in einer vertikalen Liste.Bitte blenden Sie jetzt auch den Fortschrittsbalken aus [MVP]

Regler:Danke für's Warten Sicht, Ich habe gefragt Modell zu Ihrer Suchanfrage.Es heißt, dass es eine Liste übereinstimmender Ergebnisse gefunden und diese in einer Variablen namens „searchResultsList“ in seiner Instanz gespeichert hat.Sie können es von dort erhalten.Bitte blenden Sie jetzt auch den Fortschrittsbalken aus [MVC]

Sicht:Vielen Dank Moderator [MVP]

Sicht:Vielen Dank, „Controller“ [MVC] (Jetzt die Sicht stellt sich selbst die Frage:Wie soll ich die Ergebnisse präsentieren, die ich daraus erhalte? Modell an 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: Ich habe eine Reihe von Artikeln geschrieben, die sich mit App-Architekturmustern (MVC, MVP, MVVP, saubere Architektur usw.) befassen, 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.

  • 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 (Präsentator/Controller).
    2. Sie sind im Konzept ziemlich ähnlich, die Leute initialisieren den Presenter/Controller je nach Geschmack unterschiedlich.
    3. Ein toller Artikel über die Unterschiede ist Hier.Am bemerkenswertesten ist, dass beim MVC-Muster das Modell die Ansicht aktualisiert.

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

Wenn Sie die passive Ansicht verwenden, implementiert Ihre Ansicht normalerweise eine feinkörnige Schnittstelle mit Eigenschaften, die mehr oder weniger direkt dem zugrunde liegenden UI-Widget zugeordnet sind.Beispielsweise 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 kommuniziert mit dem Modell und „ordnet“ es der Ansicht zu.Dieser Ansatz wird als „Passive View“ bezeichnet.Der Vorteil besteht darin, dass die Ansicht einfach zu testen ist und es einfacher ist, zwischen UI-Plattformen (Web, Windows/XAML usw.) zu wechseln.Der Nachteil besteht darin, dass Sie Dinge wie die Datenbindung nicht nutzen können (was ja der Fall ist). Wirklich Leistungsstark 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 namens „Customer“, die wiederum datengebunden an die UI-Widgets ist.Sie müssen nicht über die Synchronisierung und Mikroverwaltung der Ansicht nachdenken, und der Supervising Controller kann bei Bedarf eingreifen und helfen, beispielsweise bei der Erstellung einer vollständigen Interaktionslogik.

Die dritte „Variante“ von MVP (oder jemand würde es vielleicht als separates Muster bezeichnen) 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 zur UI-Architektur gefunden habe, ist die Reihe von Blogbeiträgen von Jeremy Miller bei Das Inhaltsverzeichnis der „Build Your Own CAB“-Serie.Er deckte alle Varianten von MVP ab und zeigte C#-Code für deren Implementierung.

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

Model View Controller

MVC ist 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.Außerdem werden Anwendungen dadurch flexibler und iterationsfreundlicher. Eine Anwendung wird in die folgenden Komponenten unterteilt:

  • Modelle für den Umgang mit Daten und Geschäftslogik
  • Controller für den Umgang mit der Benutzeroberfläche und der Anwendung
  • Ansichten für den Umgang mit Objekten und Präsentationen grafischer Benutzeroberflächen

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

enter image description here

Model-View-Presenter

  • Der Modell sind die Daten, die in der Ansicht (Benutzeroberfläche) angezeigt werden.
  • Der Sicht ist eine Schnittstelle, die Daten (das Modell) anzeigt und Benutzerbefehle (Ereignisse) an den Presenter weiterleitet, um auf diese Daten zu reagieren.Die Ansicht hat normalerweise einen Verweis auf ihren Präsentator.
  • Der Moderator ist der „Mittelsmann“ (gespielt vom Controller in MVC) und hat Verweise sowohl auf die Ansicht als auch auf das Modell. Bitte beachten Sie, dass das Wort „Modell“ ist irreführend.Es sollte eher so sein Geschäftslogik, die ein Modell abruft oder manipuliert.Zum Beispiel:Wenn Sie über eine Datenbank verfügen, in der Benutzer in einer Datenbanktabelle gespeichert sind, und Ihre Ansicht eine Liste von Benutzern anzeigen möchte, verfügt der Presenter über einen Verweis auf Ihre Datenbank-Geschäftslogik (z. B. ein DAO), von wo aus der Presenter eine Liste von Benutzern abfragt.

Wenn Sie ein Beispiel mit einfacher Implementierung sehen möchten, schauen Sie bitte nach Das Github-Beitrag

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

Was ist der Unterschied zwischen MVC Und MVP Muster?

MVC-Muster

  • Controller basieren auf Verhaltensweisen und können ansichtsübergreifend geteilt werden

  • Kann dafür verantwortlich sein, zu bestimmen, welche Ansicht angezeigt werden soll (Front-Controller-Muster).

MVP-Muster

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

  • Einfachere Unit-Tests, da die Interaktion mit der Ansicht über eine Schnittstelle erfolgt

  • Normalerweise wird die Karte eins zu eins angezeigt.Komplexe Ansichten können mehrere Moderatoren haben.

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

The Combined Pattern

Es gibt auch Einen vollständigen Vergleich von MVC, MVP und MVVM finden Sie hier

Beide Frameworks zielen darauf ab, Belange 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 (Ansicht).In einigen Fällen kann das Modell auch verwendet werden, um eine Datenquelle in eine Abstraktion höherer Ebene umzuwandeln.Ein gutes Beispiel hierfür ist die MVC Storefront-Projekt.

Es gibt eine Diskussion Hier bezüglich der 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 (nur die vom Controller bereitgestellten Variablen anzeigt).

Um vielleicht einen Eindruck vom Unterschied zwischen ASP.NET MVC und MVP zu bekommen, lesen Sie hier diese MIX-Präsentation von Scott Hanselman.

Bei beiden handelt es sich um Muster, die versuchen, Präsentation und Geschäftslogik zu trennen und so die Geschäftslogik von UI-Aspekten zu entkoppeln

Architektonisch gesehen ist MVP ein auf Page Controller basierender Ansatz, während MVC ein auf Front Controller basierender Ansatz ist.Das bedeutet, dass im MVP-Standard-Webformular der Seitenlebenszyklus lediglich durch Extrahieren der Geschäftslogik aus dem Code dahinter verbessert wird.Mit anderen Worten: Die Seite ist diejenige, die die HTTP-Anfrage bearbeitet.Mit anderen Worten, MVP ist meiner Meinung nach eine evolutionäre Art der Webform-Verbesserung.MVC und andererseits ändert sich das Spiel vollständig, da die Anforderung von der Controller -Klasse vor dem Laden abgefangen wird. Die Geschäftslogik wird dort und dann zum Endergebnis der Controller -Verarbeitung der gerade in das in dieser Seite abgeladenen Daten ausgeführt Sinn, MVC sieht (zumindest für mich) viel aus, um den Controller -Geschmack von MVP mit Routing -Engine zu überwachen

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

Die Entscheidung darüber, wie man eines davon auswählt, sollte meiner Meinung nach davon abhängen, wie viel Zeit man in die Webentwicklung vom Typ ASP NET-Webformular investiert hat.Wenn jemand sich für gut in Web-Formularen halten würde, würde ich MVP empfehlen.Wenn man sich in Dingen wie dem Seitenlebenszyklus usw. nicht so wohl fühlen würde, könnte MVC hier eine Möglichkeit sein.

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

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 Sinn von MVP meiner Meinung nach viel mehr mit der einfachen Einführung zusammen als mit irgendetwas anderem.

Wenn ich in einem Team arbeite, das bereits über gute Kenntnisse im Webformular-Entwicklungsstil verfügt, ist es viel einfacher, MVP als MVC einzuführen.Ich würde sagen, dass MVP in diesem Szenario ein schneller Erfolg ist.

Meiner Erfahrung nach ist es relativ einfach, ein Team von Web Forms auf MVP und dann von MVP auf MVC umzustellen.Der Wechsel von Webformularen zu MVC ist schwieriger.

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

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

In MVP bezieht die Ansicht Daten vom 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 die Ansicht eindrückt.

In MVP können Sie eine einzelne Ansicht haben, die mit mehreren Arten von Präsentatoren arbeitet, und einen einzelnen Präsentator, der mit verschiedenen Mehrfachansichten arbeitet.

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

In diesen Frameworks weiß die Benutzeroberfläche/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 ein Wert in der Benutzeroberfläche 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 Fahrzeugeigenschaften (Baujahr, Hersteller, Sitze usw.) der Ansicht präsentiert.Die Ansicht weiß, dass das Textfeld „Autohersteller“ die Maker-Eigenschaft des Präsentators anzeigen muss.

Sie können dann viele verschiedene Arten von Präsentatoren an die Ansicht binden, alle müssen über eine Maker-Eigenschaft verfügen – es kann sich um ein Flugzeug, einen Zug oder was auch immer handeln, die Ansicht spielt keine Rolle.Die Ansicht bezieht Daten vom Präsentator – egal von welchem ​​– solange er eine vereinbarte Schnittstelle implementiert.

Dieses Bindungsgerüst ist, wenn man es auseinandernimmt, tatsächlich der Controller :-)

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

MVC ist großartig, aber das Problem ist, dass es normalerweise pro Ansicht gesteuert wird.Controller A weiß, wie Felder von Ansicht A eingestellt 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 – was wie MVP nur ohne Bindungen ist, oder Sie müssen neu schreiben der UI-Set-Code in Controller B.

Fazit – MVP und MVC sind beide entkoppelte UI-Muster, aber MVP verwendet normalerweise ein Bindungsframework, dem MVC zugrunde liegt.Somit befindet sich MVP auf einem höheren Architekturniveau als MVC und einem Wrapper-Muster über MVC.

Meine bescheidene kurze Sicht: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 das V und das C als zwei Seiten einer einzigen unteilbaren Komponente angesehen werden können, die eher direkt an M gebunden sind, und man verfällt unweigerlich darauf, wenn man zu kürzeren Maßstäben wie UI-Steuerelementen und Basis-Widgets übergeht.Auf dieser Granularitätsebene macht MVP wenig Sinn.Wenn man dagegen größere Maßstäbe anwendet, wird die richtige Schnittstelle wichtiger, ebenso wie die eindeutige Zuweisung von Verantwortlichkeiten, und hier kommt MVP.

Andererseits kann diese Skalierungs-Faustregel sehr wenig Gewicht haben, wenn die Plattformeigenschaften bestimmte Beziehungen zwischen den Komponenten begünstigen, wie zum Beispiel im Web, wo die Implementierung von MVC einfacher zu sein scheint als von MVP.

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

Meiner Meinung nach ist MVP eine verbesserte Version von MVC, bei der Sie grundsätzlich die Frage, was Sie anzeigen möchten (die Daten), von der Art und Weise, wie Sie anzeigen möchten (die Ansicht), trennen.Presenter enthält gewissermaßen die Geschäftslogik Ihrer Benutzeroberfläche, legt implizit fest, welche Daten präsentiert werden sollen, und gibt Ihnen eine Liste dummer Ansichtsmodelle.Und wenn es an der Zeit ist, die Daten anzuzeigen, fügen Sie einfach Ihre Ansicht (die wahrscheinlich dieselben IDs enthält) in Ihren Adapter ein und legen die relevanten Ansichtsfelder mithilfe dieser Ansichtsmodelle fest, wobei nur ein Minimum an Code eingeführt wird (nur mit Settern).Der Hauptvorteil besteht darin, dass Sie Ihre UI-Geschäftslogik anhand vieler/verschiedener Ansichten testen können, z. B. beim Anzeigen von Elementen in einer horizontalen oder vertikalen Liste.

In MVC kommunizieren wir über Schnittstellen (Grenzen), um verschiedene Ebenen zusammenzufügen.Controller ist ein Plug-In für unsere Architektur, es gibt jedoch keine solche Einschränkung, 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.

Es gibt viele Versionen von MVC. In dieser Antwort geht es um die ursprüngliche MVC in Smalltalk.Kurz gesagt, das ist esimage of mvc vs mvp

Dieses Gespräch droidcon NYC 2017 – Sauberes App-Design mit Architekturkomponenten verdeutlicht es

enter image description here enter image description here

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 von der Ansicht entgegennimmt, Daten vom 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.

Ich denke, dieses Bild von Erwin Vandervalk (und das dazugehörige Artikel) ist die beste Erklärung für MVC, MVP und MVVM, ihre Ähnlichkeiten und Unterschiede.Der Artikel wird bei Suchanfragen zu „MVC, MVP und MVVM“ nicht in den Suchmaschinenergebnissen angezeigt, da der Titel des Artikels die Wörter „MVC“ und „MVP“ nicht enthält;aber es ist die beste Erklärung, denke ich.

image explaining MVC, MVP and MVVM - by Erwin Vandervalk

(Der Artikel stimmt auch mit dem überein, was Onkel Bob Martin in einem seiner Vorträge sagte:dass MVC ursprünglich für die kleinen UI-Komponenten entwickelt wurde, nicht für die Architektur des Systems)

MVP

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

Der Präsentator fungiert in MVP als Aufsichtsperson und bindet View-Ereignisse und Geschäftslogiken aus Modellen zusammen.

Die Bindung von Ansichtsereignissen wird in Presenter über eine Ansichtsschnittstelle implementiert.

View ist der Initiator für Benutzereingaben und delegiert die Ereignisse dann an Presenter. Presenter kümmert sich um Ereignisbindungen und ruft Daten von Modellen ab.

Vorteile:Die Ansicht hat nur eine Benutzeroberfläche, keine logische hohe Testbarkeitsniveaus

Nachteile:Etwas komplex und mehr Arbeit bei der Implementierung von Ereignisbindungen

MVC

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

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

Vorteile:Betonung des Prinzips der einzigen Verantwortung hohe Testbarkeitsniveau

Nachteile:Manchmal ist die Arbeitsbelastung für Controller zu hoch, wenn versucht wird, mehrere Ansichten im selben Controller zu rendern.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top