Was sind MVP und MVC und was ist der Unterschied?

2133

Wenn Sie über die RAD -Methode (Drag-Drop und Konfiguration) zum Erstellen von Benutzeroberflächen hinausblicken, die von vielen Tools empfohlen wird, stoßen Sie wahrscheinlich auf drei Entwurfsmuster: 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 sind sie ähnlich?
  3. Wie unterscheiden sie sich?
Mike Minutillo
quelle
4
mvc.givan.se/#mvp
givanse
2
IDK, aber angeblich für die ursprüngliche MVC, sollte es in der kleinen verwendet werden. Jede Schaltfläche, Beschriftung usw. hatte ihre eigene Ansicht und ihr eigenes Controller-Objekt, oder zumindest behauptet dies Onkel Bob. Ich glaube, er hat über Smalltalk gesprochen. Schauen Sie sich seine Vorträge auf YouTube an, sie sind faszinierend.
still_dreaming_1
MVP fügt eine zusätzliche Indirektionsebene hinzu, indem der View-Controller in eine Ansicht und einen Präsentator aufgeteilt wird ...
the_prole
2
Der Hauptunterschied besteht darin, dass der Controller in MVC keine Daten vom Modell an die Ansicht übergibt. Es benachrichtigt nur die Ansicht, um die Daten vom Modell selbst abzurufen. In MVP besteht jedoch keine Verbindung zwischen Ansicht und Modell. Der Präsentator selbst erhält alle vom Modell benötigten Daten und übergibt sie zur Anzeige an die Ansicht. Mehr dazu zusammen mit einem Android-Beispiel in allen Architekturmustern finden Sie hier: digigene.com/category/android/android-architecture
Ali Nem
Sie werden Architekturmuster genannt, keine Entwurfsmuster . Wenn Sie den Unterschied wissen wollen, überprüfen Sie dies
Hasan El-Hefnawy

Antworten:

1997

Model-View-Presenter

In MVP enthält der Presenter 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. Mehr über beide Varianten erfahren Sie .

Zwei Hauptvarianten

Passive Ansicht: Die Ansicht ist so dumm wie möglich und enthält eine Logik von nahezu Null. 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 zeigt die Ansicht Setter-Eigenschaften an, mit denen der Presenter die Daten festlegt. Der gesamte Status wird im Presenter und nicht in der Ansicht verwaltet.

  • Pro: maximale Testbarkeit Oberflä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 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 der MVC ist der Controller 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:

    Aktion in der Ansicht
        -> Controller anrufen
        -> Controller-Logik
        -> 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 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 zu betrachtendes Muster ist das Prä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 offenlegen kann, die man niemals einem Domänenmodell zuweisen würde, 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 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 kapselt.Model-View-ViewModel .

Es gibt einen MSDN-Artikel über das Präsentationsmodell und einen Abschnitt in der Composite Application Guidance für WPF (ehemals Prism) über getrennte Präsentationsmuster

Glenn Block
quelle
27
Können Sie diesen Satz bitte klarstellen? 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. Für mich klingt es wie das Gleiche, aber ich bin sicher, Sie beschreiben etwas anderes.
Panzercrisis
16
@Panzercrisis Ich bin mir nicht sicher, ob der Autor dies gemeint hat, aber ich denke, das haben sie versucht zu sagen. Wie diese Antwort - stackoverflow.com/a/2068/74556 erwähnt, basieren Controller-Methoden in MVC auf Verhaltensweisen - mit anderen Worten, Sie können einem einzelnen Controller mehrere Ansichten (aber dasselbe Verhalten) zuordnen . In MVP ist der Präsentator näher an die Ansicht gekoppelt und führt normalerweise zu einer Zuordnung, die näher an der Eins-zu-Eins liegt, dh eine Ansichtsaktion wird der Methode des entsprechenden Präsentators zugeordnet. Normalerweise würden Sie die Aktionen einer anderen Ansicht nicht der Methode eines anderen Präsentators (aus einer anderen Ansicht) zuordnen.
Dustin Kendall
2
Beachten Sie, dass dies MVC häufig von Web-Frameworks verwendet wird Laravel, bei denen die empfangenen URL-Anforderungen (möglicherweise von Benutzern gestellt) von der verarbeitet werden Controllerund der von der generierte HTML-Code Viewan den Client gesendet wird. Dies Viewist also ein Teil des Backends und der Benutzer können niemals direkt darauf zugreifen, und wenn Sie irgendwo das Gegenteil feststellen, betrachten Sie dies als MVC-Erweiterung (oder sogar als Verstoß). @Panzercrisis, Dies unterscheidet sich von MVP(wie im AndroidBetriebssystem verwendet), wo actions route through the View to the Presenterund Benutzer direkten Zugriff auf die haben View.
Top-Master
455

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

Geben Sie hier die Bildbeschreibung ein

Phyxx
quelle
10
Dies ist eine großartige Darstellung des Schaltplans, die die Abstraktion und vollständige Isolierung aller GUI-bezogenen (Ansichtsmaterialien) von der API des Präsentators zeigt. Ein kleiner Punkt: Ein Master-Präsentator kann verwendet werden, wenn nur ein Präsentator vorhanden ist und nicht einer pro Ansicht, aber Ihr Diagramm ist das sauberste. IMO, der größte Unterschied zwischen MVC / MVP besteht darin, dass MVP versucht, die Ansicht völlig frei von etwas anderem als der Anzeige des aktuellen Ansichtsstatus (Ansichtsdaten) zu halten, während der Ansicht auch jegliches Wissen über Modellobjekte untersagt wird. Daher müssen die Schnittstellen vorhanden sein, um diesen Zustand zu injizieren.
4
Gutes Bild. Ich benutze MVP ziemlich oft, deshalb möchte ich einen Punkt hervorheben. Nach meiner Erfahrung müssen die Moderatoren ziemlich oft miteinander sprechen. Gleiches gilt für die Modelle (oder Geschäftsobjekte). Aufgrund dieser zusätzlichen "blauen Kommunikationslinien" in Ihrem MVP-Bild können sich die Presenter-Model-Beziehungen ziemlich verwickeln. Daher neige ich dazu, eine Eins-zu-Eins-Beziehung zwischen Moderator und Modell im Vergleich zu einer Eins-zu-Viele-Beziehung aufrechtzuerhalten. Ja, es sind einige zusätzliche Delegierungsmethoden für das Modell erforderlich, aber es reduziert viele Kopfschmerzen, wenn sich die API des Modells ändert oder umgestaltet werden muss.
Splungebob
3
Das MVC-Beispiel ist falsch. Es gibt eine strikte 1: 1-Beziehung zwischen Ansichten und Controllern. Per Definition interpretiert eine Steuerung die Eingabe menschlicher Gesten, um Ereignisse für das Modell und die Ansicht für eine einzelne Steuerung gleichermaßen zu erzeugen. Einfacher gesagt war MVC nur für die Verwendung mit einzelnen Widgets vorgesehen. Ein Widget, eine Ansicht, ein Steuerelement.
Samuel A. Falvo II
3
@ SamuelA.FalvoII nicht immer, es gibt eine 1: Viele zwischen Controllern und Ansichten in ASP.NET MVC: stackoverflow.com/questions/1673301/…
StuperUser
4
@StuperUser - Ich bin mir nicht sicher, was ich dachte, als ich das schrieb. Sie haben natürlich Recht, und wenn ich auf das zurückblicke, was ich geschrieben habe, muss ich mich fragen, ob ich einen anderen Kontext im Sinn hatte, den ich nicht artikuliert habe. Danke für die Korrektur.
Samuel A. Falvo II
421

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

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 Karte 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.

Jon Limjap
quelle
15
Ich verstehe nicht, wie in der Ansicht mehr oder weniger eng mit dem Modell gekoppelt werden kann, wenn es in beiden Fällen darum geht, sie vollständig zu entkoppeln. Ich will damit nicht sagen, dass Sie etwas Falsches gesagt haben - nur verwirrt darüber, was Sie meinen.
Bill K
18
@pst: Mit MVP ist es wirklich 1 View = 1 Presenter. Mit MVC kann der Controller mehrere Ansichten steuern. Das war's wirklich. Stellen Sie sich beim Modell "Registerkarten" vor, dass jede Registerkarte einen eigenen Präsentator hat und nicht einen Controller für alle Registerkarten.
Jon Limjap
4
Ursprünglich gibt es zwei Arten von Controllern: den, von dem Sie sagten, dass er für mehrere Ansichten freigegeben ist, und diejenigen, die für bestimmte Ansichten spezifisch sind und hauptsächlich dazu dienen, die Schnittstelle des gemeinsam genutzten Controllers anzupassen.
Acsor
1
@ JonLimjap Was bedeutet es überhaupt mit einer Ansicht? Ist es im Kontext der iOS-Programmierung ein Bildschirm? Ist der iOS-Controller dadurch eher MVP als MVC? (Auf der anderen Seite können Sie auch mehrere iOS-Controller pro Bildschirm haben)
Huggie
2
Nun, die grafische Darstellung von MVC durch Todd widerspricht völlig der Idee, Ansicht und Modell zu entkoppeln. Wenn Sie sich das Diagramm ansehen, heißt es "Modell aktualisiert Ansicht" (Pfeil von Modell zu Ansicht). In welchem ​​Universum befindet sich ein System, in dem das Modell direkt mit der Ansicht interagiert, ein entkoppeltes ???
Ash
260

Hier sind Abbildungen, die den Kommunikationsfluss darstellen

Geben Sie hier die Bildbeschreibung ein

Geben Sie hier die Bildbeschreibung ein

Ashraf Bashir
quelle
44
Ich habe eine Frage zum MVC-Diagramm. Ich bekomme nicht den Teil, in dem die Ansicht zum Abrufen von Daten ausgeht. Ich würde denken, der Controller würde mit den benötigten Daten an die Ansicht weiterleiten.
Brian Rizo
54
Wenn ein Benutzer auf eine Schaltfläche klickt, wie interagiert das nicht mit der Ansicht? Ich fühle mich wie in MVC, der Benutzer interagiert mehr mit der Ansicht als der Controller
Jonathan
5
Ich weiß, dass dies eine alte Antwort ist - aber könnte jemand auf @ JonathanLeaders Punkt antworten? Ich komme aus einem Winforms-Hintergrund, es sei denn, Sie haben eine sehr eindeutige Codierung vorgenommen. Wenn Sie auf die Benutzeroberfläche / Ansicht klicken, wird dieser Klick vor allem anderen bekannt. Zumindest soweit ich weiß?
Rob P.
6
@RobP. Ich denke, diese Art von Diagrammen ist immer entweder zu komplex oder zu einfach. Imo gilt der Ablauf des MVP-Diagramms auch für eine MVC-Anwendung. Abhängig von den Sprachfunktionen (Datenbindung / Beobachter) kann es zu Abweichungen kommen. Letztendlich besteht die Idee darin, die Ansicht von den Daten / der Logik der Anwendung zu entkoppeln.
Luca Fülbier
15
@ JonathanLeaders Menschen haben wirklich verschiedene Dinge im Sinn, wenn sie "MVC" sagen. Die Person, die dieses Diagramm erstellt hat, hatte wahrscheinlich die klassische Web-MVC im Sinn, bei der die "Benutzereingabe" HTTP-Anforderungen sind und "an den Benutzer zurückgegebene Ansicht" eine gerenderte HTML-Seite ist. Daher ist eine Interaktion zwischen einem Benutzer und einer Ansicht aus der Sicht eines Autors der klassischen Web-MVC-App "nicht vorhanden".
cubuspl42
170

MVP ist nicht unbedingt ein Szenario, in dem die Ansicht zuständig ist (siehe beispielsweise 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" (Pragmatic Programmer) widerspricht. "Es ist nur eine Ansicht" besagt, dass die endgültige Ansicht, die dem Benutzer angezeigt wird, ein sekundäres Anliegen der Anwendung ist. Microsoft MVP - Muster macht die Wiederverwendung von Ansichten viel schwieriger und bequem Ausreden Microsofts Designer von schlechter Praxis 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 erzielen, wen interessiert es dann wirklich, ob Ihr Muster MVC, MVP oder Supervising Controller ist? Das einzige wirkliche Muster bleibt MVC, der Rest sind nur unterschiedliche Geschmacksrichtungen.

Betrachten Sie diesen äußerst spannenden Artikel, in dem einige dieser unterschiedlichen Implementierungen umfassend aufgelistet sind. 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 die 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.

Streit
quelle
28
Ich habe mehrere Antworten und Blogs über die Unterschiede zwischen MVC / MVP / MVVM / etc 'gelesen. In der Tat ist es alles das Gleiche, wenn Sie geschäftlich unterwegs sind. Es spielt keine Rolle, ob Sie eine Schnittstelle haben oder nicht und ob Sie einen Setter (oder eine andere Sprachfunktion) verwenden. Es scheint, dass der Unterschied zwischen diesen Mustern eher aus dem Unterschied der Implementierungen verschiedener Frameworks als aus einer Frage des Konzepts resultiert.
Michael
6
Ich würde MVP nicht als Anti-Pattern bezeichnen , da später in dem Beitrag "..der Rest [einschließlich MVP] sind nur unterschiedliche Geschmacksrichtungen von [MVC] ..", was bedeuten würde, dass MVP ein Anti-Pattern wäre war MVC ... es ist nur eine Variante für den Ansatz eines anderen Frameworks. (Nun, einige spezifische MVP-Implementierungen könnten mehr oder weniger wünschenswert sein als einige spezifische MVC-Implementierungen für verschiedene Aufgaben ...)
@Quibblsome: „Ich persönlich denke, MVP wurde erst kürzlich als eingängiger Begriff wieder eingeführt, um entweder die Argumente zwischen semantischen Bigots zu reduzieren, die darüber streiten, ob etwas wirklich MVC ist oder nicht. […] Keiner dieser Gründe in meinen Büchern rechtfertigt seine Existenz als separates Designmuster. “ . Es unterscheidet sich genug, um es deutlich zu machen. In MVP kann die Ansicht alles sein, was eine vordefinierte Schnittstelle erfüllt (die Ansicht in MVP ist eine eigenständige Komponente). In MVC wird der Controller für eine bestimmte Ansicht erstellt (wenn die Aritäten der Beziehung jemandem das Gefühl geben, dass dies einen anderen Begriff wert ist).
Hibou57
6
@ Hibou57, nichts hindert MVC daran, die Ansicht als Schnittstelle zu referenzieren oder einen generischen Controller für mehrere verschiedene Ansichten zu erstellen.
Quibblesome
1
Samuel, bitte kläre, wovon du sprichst. Wenn Sie mir nicht die Geschichte des Teams erzählen, das MVC "erfunden" hat, bin ich unglaublich zweifelhaft in Bezug auf Ihren Text. Wenn Sie nur über WinForm sprechen, gibt es andere Möglichkeiten, Dinge zu tun, und ich habe WinForm-Projekte erstellt, in denen Steuerelementbindungen vom Controller verwaltet werden, nicht "einzelne Steuerelemente".
Quibblesome
110

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.

Brian Leahy
quelle
3
"View kennt Controller nicht." Ich denke du meinst, dass die Ansicht keinen direkten Kontakt zum Modell hat?
Lotus Notes
2
Ansicht sollte nie über das Modell in einem anderen wissen.
Brian Leahy
4
@Brian: "Die Ansicht erstellt in den meisten Fällen den Presenter." . Ich habe meistens das Gegenteil gesehen, als der Presenter sowohl das Modell als auch die Ansicht startete. Nun, die Ansicht startet möglicherweise auch den Presenter, aber dieser Punkt ist nicht wirklich der markanteste. Was am wichtigsten ist, passiert später im Leben.
Hibou57
2
Möglicherweise möchten Sie Ihre Antwort bearbeiten, um weitere Erläuterungen zu erhalten: Da die Ansicht nichts über den Controller weiß, werden Benutzeraktionen, die für die visuellen Elemente ausgeführt werden, die der Benutzer auf dem Bildschirm sieht (dh die Ansicht), an den Controller übermittelt ...
Ash
77

Geben Sie hier die Bildbeschreibung ein

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.

Weitere Informationen

AVI
quelle
Ist MVPder Präsentator beim Laden der Anwendung zum ersten Mal nicht dafür verantwortlich, die erste Ansicht zu laden? Ist der Moderator nicht wie beim Laden der Facebook-Anwendung für das Laden der Anmeldeseite verantwortlich?
Viper
2
Ein Link vom Modell zur Ansicht in MVC? Möglicherweise möchten Sie Ihre Antwort bearbeiten, um zu erklären, wie dies unter diesem Link zu einem "entkoppelten" System führt. Hinweis: Möglicherweise fällt es Ihnen schwer. Wenn Sie nicht glauben, dass der Leser gerne akzeptiert, dass er sein ganzes Leben lang falsch berechnet hat, möchten Sie möglicherweise erläutern, warum Aktionen in MVC zuerst über den Controller ausgeführt werden, obwohl der Benutzer mit den "visuellen" Elementen auf dem Bildschirm interagiert (z Ansicht), keine abstrakte Ebene, die sich hinter der Verarbeitung befindet.
Ash
3
Dies ist eindeutig falsch ... in MVC spricht das Modell nie direkt mit der Ansicht und umgekehrt. Sie wissen nicht einmal, dass es einen anderen gibt. Der Controller ist der Klebstoff, der sie zusammenhält
MegaManX
1
Ich stimme Ash und MegaManX zu. Im MVC-Diagramm sollte der Pfeil von der Ansicht auf das Modell (oder ViewModel oder DTO) zeigen, nicht vom Modell zur Ansicht. weil das Modell nichts über die Ansicht weiß, die Ansicht jedoch möglicherweise über das Modell Bescheid weiß.
Jboy Flaga
57

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 ...

Ansicht : Wer ist das? [ MVP | MVC ]

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

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

( Ansicht, die den Presenter | Controller aufruft …) [ MVP | MVC ]

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

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

Ansicht : Ja,… hier ist es… „Klavier“ [ MVP | MVC ]

Moderator : Danke View ,… während ich den Suchbegriff für das Modell nachschlage, zeigen Sie ihm / ihr bitte einen Fortschrittsbalken [ MVP | MVC ]

( Presenter | Controller ruft das Modell auf …) [ MVP | MVC ]

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

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

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

( Nach einer Weile ... )

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

Modell : Ich habe eine Liste für Sie gefunden, Moderator , hier in JSON "[{" Name ":" Klavierlehrer "," Jahr ": 2001}, {" Name ":" Klavier "," Jahr ": 1993} ] ”[ MVP ]

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

( Presenter | Controller bedankt sich bei Model und kehrt zur Ansicht zurück ) [ MVP | MVC ]

Moderator : Vielen Dank für das Warten View , ich 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 ]

Controller : Vielen Dank, dass Sie auf View gewartet haben. Ich habe Model nach Ihrer Suchanfrage gefragt . 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 ]

Ansicht : Vielen Dank Presenter [ MVP ]

Ansicht : Vielen Dank, "Controller" [ MVC ] (Jetzt stellt sich die Ansicht selbst die Frage: Wie soll ich dem Benutzer die Ergebnisse präsentieren, die ich vom Modell erhalte ? Sollte das Produktionsjahr des Films zuerst oder zuletzt kommen ...? Sollte es sein in einer vertikalen oder horizontalen Liste sein? ...)

Falls Sie interessiert sind, habe ich eine Reihe von Artikeln geschrieben, die sich mit Architekturmustern von Apps (MVC, MVP, MVVP, saubere Architektur, ...) 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.

Ali Nem
quelle
Grundsätzlich versuchen Sie zu sagen, dass der Controller die Ansichtslogik mikromanagt? Die Ansicht wird dümmer, indem dargestellt wird, was und wie in Ansichten geschieht.
Radu
@ Radu, Nein, es ist kein Mikromanagement, das ist es, was der Moderator tut, indem er die Ansicht passiv oder dumm macht
Ali Nem
4
In einer ordnungsgemäßen MVC ruft die Ansicht Funktionen auf dem Controller auf und lauscht auf Datenänderungen im Modell. Die Ansicht erhält keine Daten von der Steuerung, und die Steuerung sollte die Ansicht NICHT anweisen, beispielsweise eine Ladeanzeige anzuzeigen. Mit einer geeigneten MVC können Sie den Ansichtsteil durch einen grundlegend anderen ersetzen. Der Ansichtsteil enthält eine Ansichtslogik, die eine Ladeanzeige enthält. Die Ansicht ruft Anweisungen auf (in der Steuerung), die Steuerung ändert Daten im Modell und das Modell benachrichtigt seine Listener über Änderungen an seinen Daten. Ein solcher Listener ist die Ansicht.
Tommy Andersen
35
  • 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 ist hier . Am bemerkenswertesten ist, dass das MVC-Muster das Modell hat, das die Ansicht aktualisiert.
Brett Veenstra
quelle
2
Modell zur Aktualisierung des VIew. Und das ist immer noch ein entkoppeltes System?
Ash
34

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. Es macht Anwendungen auch flexibler und begrüßt Iterationen. Es unterteilt eine Anwendung in die folgenden Komponenten:

  • Modelle für den Umgang mit Daten und Geschäftslogik
  • Controller für die Handhabung der Benutzeroberfläche und 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. 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.

Geben Sie hier die Bildbeschreibung ein

Model-View-Presenter

  • Das Modell sind die Daten, die in der Ansicht (Benutzeroberfläche) angezeigt werden.
  • Die Ansicht ist 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.
  • Der Presenter ist der „Middle-Man“ (vom Controller in MVC gespielt) und verweist sowohl auf die Ansicht als auch auf das Modell. Bitte beachten Sie, dass das Wort "Modell" irreführend ist. Es sollte eher eine Geschäftslogik sein, 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, lesen Sie bitte diesen GitHub-Beitrag

Ein konkreter Workflow zum Abfragen und Anzeigen einer Liste von Benutzern aus einer Datenbank könnte folgendermaßen funktionieren: Geben Sie hier die Bildbeschreibung ein

Was ist der Unterschied zwischen MVC- und MVP- Mustern?

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 Karte eins zu eins angezeigt. Komplexe Ansichten können mehrere Präsentatoren haben.

Rahul
quelle
2
nee, es gibt keine direkte verbindung zwischen ansicht und modell in mvc. Ihr Diagramm ist falsch.
Özgür
33

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.

Bei Verwendung der passiven Ansicht 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önnen (was in Frameworks wie WPF und Silverlight sehr leistungsfähig ist ).

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 Mikromanagement 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 im Inhaltsverzeichnis der CAB-Serie "Build Your Own" verfasst hat . 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 YouCard erneut gebloggt: Implementierung des ViewModel-Musters .

Jonas Follesø
quelle
25

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

Das kombinierte Muster

Hier gibt es auch einen vollständigen Vergleich von MVC, MVP und MVVM

Xiaoguo Ge
quelle
1
Anstatt die Dinge zu komplizieren, hätten Sie die Frage beantworten können. Deshalb sind die meisten von uns hier. Sie haben nach einem Vergleich zwischen mvp und mvc gesucht und wurden hier umgeleitet, und Sie sprechen von der Harmonie dieser Architekturen, die nichts mit OP zu tun hat.
Farid
18

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 hierfür ist das MVC Storefront-Projekt .

Es gibt eine Diskussion hier in Bezug auf die Unterschiede zwischen MVC vs 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).

In dieser MIX-Präsentation von Scott Hanselman können Sie sich vielleicht ein Bild von der Unterscheidung zwischen ASP.NET MVC und MVP machen .

Matt Mitchell
quelle
7
MVC und MVP sind Muster, keine Frameworks. Wenn Sie ehrlich denken, dass es bei diesem Thema um .NET Framework ging, dann ist es so, als würde man "das Internet" hören und denken, es geht um IE.
Tereško
Ich bin mir ziemlich sicher, dass sich die Frage seit ihrer ersten Beantwortung im Jahr 2008 erheblich weiterentwickelt hat. Wenn ich auf meine Antwort zurückblicke (und dies war vor 4 Jahren, also habe ich nicht viel mehr Kontext als Sie), würde ich sagen, dass ich allgemein anfange und Verwenden Sie dann .NET MVC als konkretes Beispiel.
Matt Mitchell
13

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 auf Page Controller basierender Ansatz, während MVC auf Front Controller basiert. 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 Webform-Verbesserung. 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 dann 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

Nikola Malovic
quelle
9

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

Pedro Santos
quelle
8

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 festlegt.

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 von 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.

James Roeiter
quelle
6

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.

Hibou57
quelle
4

Ich denke, dieses Bild von Erwin Vandervalk (und dem dazugehörigen Artikel ) ist die beste Erklärung für MVC, MVP und MVVM, ihre Ähnlichkeiten und ihre Unterschiede. Der Artikel wird 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.

Bild zur Erklärung von MVC, MVP und MVVM - von Erwin Vandervalk

(Der Artikel entspricht auch dem, 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.)

Jboy Flaga
quelle
3

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

Dieser Vortrag droidcon NYC 2017 - Sauberes App-Design mit Architekturkomponenten verdeutlicht dies

Geben Sie hier die Bildbeschreibung ein Geben Sie hier die Bildbeschreibung ein

onmyway133
quelle
6
In der MVC wird das Modell nie direkt aus der Sicht
aufgerufen
5
Dies ist eine ungenaue Antwort. Lass dich nicht irreführen. Wie @rodi schreibt, gibt es keine Interaktion zwischen Ansicht und Modell.
Shawn Mehan
Das MVC-Bild ist ungenau oder bestenfalls irreführend. Bitte beachten Sie diese Antwort nicht.
Jay
2
@ Jay1b Welche MVC ist deiner Meinung nach "richtig"? Diese Antwort bezieht sich auf die ursprüngliche MVC. Es gibt viele andere MVC (wie in iOS), die geändert wurden, um sich an die Plattform anzupassen, sagen wir wieUIKit
onmyway133
Was bedeuten die Pfeile?
problemofficer
3

Es gibt dieses schöne 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. Der Präsentator 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 die Zeit gekommen ist, um 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. Ein Controller ist ein Plug-In für unsere Architektur, aber es gibt keine solche Einschränkung, um festzulegen, 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.

Ich hoffe das hilft besser.

stdout
quelle
2
Wichtiger Punkt von Onkel Bob: Als MVC ursprünglich von Trygve Reenskaug erfunden wurde, war es für jedes Widget gedacht, nicht für das gesamte Formular.
Basil Bourque
2

Sie haben Action-Domain-Responder ( ADR ) vergessen .

Wie in einigen Grafiken oben erläutert, besteht eine direkte Beziehung / Verknüpfung zwischen dem Modell und der Ansicht in MVC. Auf dem Controller wird eine Aktion ausgeführt, die eine Aktion auf dem Modell ausführt . Diese Aktion im Modell , wird eine Reaktion auslösen in der Ansicht . Die Ansicht wird immer aktualisiert, wenn sich der Status des Modells ändert.

Einige Leute vergessen immer wieder, dass MVC Ende 70 " und das Web erst Ende 80" / Anfang 90 "erstellt wurde. MVC wurde ursprünglich nicht für das Web erstellt, sondern für Desktop-Anwendungen, bei denen der Controller verwendet wurde , Modell und Ansicht würden zusammen existieren.

Da wir Web-Frameworks ( z. B. Laravel ) verwenden, die immer noch dieselben Namenskonventionen verwenden ( Model-View-Controller ), denken wir, dass es MVC sein muss, aber es ist tatsächlich etwas anderes.

Schauen Sie sich stattdessen Action-Domain-Responder an . In ADR erhält der Controller eine Aktion , die eine Operation im Modell / in der Domäne ausführt . Soweit das gleiche. Der Unterschied besteht darin, dass dann die Antwort / Daten dieser Operation gesammelt und zum Rendern an einen Responder ( z. B.view() ) übergeben werden. Wenn eine neue Aktion für dieselbe Komponente angefordert wird, wird der Controller erneut aufgerufen und der Zyklus wiederholt sich. In ADR besteht keine Verbindung zwischen dem Modell / der Domäne und der Ansicht ( Antwort des Reponsers ).

Hinweis: Wikipedia gibt an, dass " jede ADR-Aktion jedoch durch separate Klassen oder Abschlüsse dargestellt wird ". Dies ist nicht unbedingt wahr. In einem Controller können sich mehrere Aktionen befinden, und das Muster ist immer noch dasselbe.

Hugo Rafael Azevedo
quelle
2

Die einfachste Antwort ist, wie die Ansicht mit dem Modell interagiert. In MVP wird die Ansicht vom Präsentator aktualisiert, der als Vermittler zwischen der Ansicht und dem Modell fungiert. Der Präsentator übernimmt die Eingabe aus der Ansicht, die die Daten aus dem Modell abruft, die erforderliche Geschäftslogik ausführt und anschließend die Ansicht aktualisiert. In MVC aktualisiert das Modell die Ansicht direkt, anstatt über den Controller zurückzukehren.

Clive Jefferies
quelle
Ich habe abgestimmt, weil afaik das Modell nichts über die Ansicht in MVC weiß und es nicht in der Lage ist, sie direkt zu aktualisieren, während Sie schreiben.
Problemoffizier
1
Schauen Sie sich MVC auf Wikipedia an, genau so funktioniert es.
Clive Jefferies
1
Unabhängig davon, ob es den Lesern gefällt oder nicht, viele Quellen, die durch Googeln gefunden werden können, geben an, dass die Ansicht in MVC Aktualisierungen des Modells abonniert. und in einigen Fällen kann sogar sein , die Steuerung und damit invoke solche Updates. Wenn dir das nicht gefällt, dann beschwere dich über diese Artikel oder zitiere, welche 'Bibel' deiner Meinung nach die einzige legitime Quelle ist, anstatt Antworten herunterzustimmen, die nur die anderen verfügbaren Informationen weitergeben!
underscore_d
1
Der Wortlaut könnte definitiv verbessert werden, aber es stimmt, dass die Ansicht Änderungen im Modell in MVC abonniert. Das Modell muss die Ansicht in MVC nicht kennen.
verschlang Elysium
Vielen Dank. Es hat mir sehr geholfen
Dvyn Resh
1
  • 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.
Chinmai Kulkarni
quelle
-1

MVP

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

Ein Präsentator fungiert als Aufsichtsfunktion in MVP, die View-Ereignisse und Geschäftslogik aus Modellen bindet.

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

Die Ansicht ist der Initiator für Benutzereingaben und delegiert die Ereignisse an den Präsentator. Der Präsentator verarbeitet Ereignisbindungen und ruft Daten von Modellen ab.

Vorteile: Die Ansicht 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 Arbeit für Controller, wenn Sie versuchen, mehrere Ansichten in demselben Controller zu rendern.

MarvelTracker
quelle