Was sind die Verbesserungen von MVP gegenüber MVC?

Ich habe drei Tage lang über die Muster Model-View-Controller (MVC) und Model-View-Presenter (MVP) gelesen . Und es gibt eine Frage, die mich sehr stört. Warum haben Software-Designer MVP erfunden, als es bereits eine MVC gab?

Welche Probleme hatten sie, die MVC nicht (oder schlecht) gelöst hat, die MVP aber lösen kann? Welche Probleme soll MVP lösen?

Ich habe viele Artikel über die Geschichte und Erklärung von MVP oder über Unterschiede zwischen MVC und MVP gelesen, aber keine hatte eine klare Antwort auf meine Fragen.

In einem der Artikel, die ich las, hieß es:

Nun zu Model View Presenter, einer Antwort auf die Unzulänglichkeiten des MVC-Musters bei der Anwendung auf moderne komponentenbasierte grafische Benutzeroberflächen. In modernen GUI-Systemen handhaben GUI-Komponenten selbst Benutzereingaben wie Mausbewegungen und Klicks und nicht irgendeine zentrale Steuerung.

Ich kann es nicht verstehen, aber kann es auch anders sein, dass GUI-Komponenten Benutzereingaben nicht selbst handhaben? Und was genau bedeutet "von selbst handhaben"?

— Sieger
quelle

Duplikat von stackoverflow.com/questions/2056/…

— qwerty_so

Ich denke, es ist nur "The Emperor's New Clothes", ein neues Schlagwort von Mickeysoft.

— Qwerty_so

Victor, hast du eine andere Frage als "Warum gibt es zwei verschiedene Muster?" Es gibt zwei verschiedene Muster, weil sie dasselbe Problem auf zwei unterschiedliche Arten lösen. Wenn dies hilft, sind das Modell und die Ansicht in beiden Mustern im Wesentlichen gleich. Konzentrieren Sie sich auf die Unterschiede zwischen einem Controller und einem Presenter. Weitere Hilfe finden Sie hier: linkedin.com/pulse/…

— Robert Harvey

"Ich habe drei Tage lang über MVC- und MVP-Muster gelesen." Huch. Ich schlage vor, Sie nehmen ein entspannendes heißes Bad oder lassen ein paar Steine über einen mit Enten gefüllten Teich oder so. Diese Art des Lesens kann ohne praktische Anwendung Ihr Gehirn zum Schmelzen bringen!

— user1172763

Die Art und Weise, wie Sie die gewünschte Antwort erhalten, besteht darin , etwas anhand dieser Muster zu erstellen. Dann wirst du erleuchtet.

— Robert Harvey

Antworten:

MVC ist konzeptionell elegant:

Benutzereingaben werden von der Steuerung übernommen
Der Controller aktualisiert das Modell
Das Modell aktualisiert die Ansicht / Benutzeroberfläche

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

Allerdings: Der Daten- und Ereignisfluss in MVC ist zirkulär. Die Ansicht enthält häufig wichtige Logik (z. B. Ereignishandler für Benutzeraktionen). Zusammengenommen machen diese Eigenschaften das System schwierig zu testen und zu warten.

Die MVP-Architektur ersetzt den Controller durch einen Presenter, der zwischen der Ansicht und dem Modell vermittelt. Dies linearisiert das System:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

Dies hat folgende Vorteile:

Logik (wie Ereignishandler und Benutzeroberflächenstatus) kann aus der Ansicht in den Präsentator verschoben werden.
Die Benutzerschnittstelle kann in Bezug auf den Präsentator einem Unit-Test unterzogen werden, da sie den Status der Benutzerschnittstelle beschreibt. Während des Unit-Tests ersetzen wir die Ansicht durch einen Testtreiber, der den Moderator anruft.
Da die Benutzeroberfläche von der Anwendungslogik isoliert ist, können beide unabhängig voneinander entwickelt werden.

Dieser Ansatz hat jedoch auch einige Nachteile:

Es erfordert mehr Aufwand.
Der Moderator kann leicht zu einer unerreichbaren „Gottesklasse“ mutieren.
Die Anwendung verfügt nicht über eine einzelne MVP-Achse, sondern über mehrere Achsen: eine für jeden Bildschirm / jedes Fenster / jedes Bedienfeld in der Benutzeroberfläche. Dies kann entweder Ihre Architektur vereinfachen oder sie schrecklich überkomplizieren.

— amon
quelle

Gute Antwort, aber in der heutigen MVC werden Ereignishandler (wenn überhaupt) im Allgemeinen nicht häufig verwendet, außer vielleicht für die lokale Formularüberprüfung, und ich halte diese Ereignisse nicht für einen angemessenen Bestandteil von MVC. Deshalb haben wir MVP und MVVM. MVC ist im Wesentlichen serverseitig.

— Robert Harvey

@amon, danke für deine Antwort, es sagt mir vieles. Und Sie erwähnen, dass mehrere Achsen in der Anwendung die Architektur vereinfachen können. Ich begegne dieser Idee in vielen Artikeln, und es wurde als einer der Hauptgründe für die Erfindung von MVP erwähnt, weil MVC nicht den Anforderungen komplexer GUIs entspricht. Welche Anforderungen werden von MVP erfüllt und wie werden diese Anforderungen gelöst? Es tut mir leid, dass ich so hartnäckig bin, aber ich verstehe es WIRKLICH gut.

— Victor

@ Victor Es gibt kein bestes Muster, aber die Kompromisse sind unterschiedlich. MVC kann komplizierten Anforderungen gewachsen sein. In Bezug auf die Architektur erzwingt MVP eine 1: 1-Beziehung zwischen Ansichten und Präsentatoren: Jede Ansicht hat einen eigenen Präsentator, jeder Präsentator ist mit einer Ansicht verbunden. In MVC gibt es eine n: m-Beziehung: Eine Ansicht kann Benutzereingaben an mehrere verschiedene Controller senden, und ein Controller kann Eingaben von mehreren Ansichten empfangen. Das ist flexibler, aber auch chaotischer - es gibt keine klare „Achse“ in MVC.

— amon

@ Victor Ich habe nicht viel Erfahrung mit GUIs, daher gibt es wahrscheinlich eine Menge, die ich nicht erwähnt habe. Die letzte GUI, die ich gemacht habe, war ein absolutes Chaos, weil ich zu diesem Zeitpunkt noch nichts über MVP wusste - ein linearisierter Daten- und Kontrollfluss wäre eine enorme Verbesserung gewesen.

— amon

@RobertHarvey Ich würde argumentieren, dass das, was das Web "MVC" nennt, nach der ursprünglichen Definition überhaupt nie wirklich "MVC" war. Wer das Akronym gekapert hat, sollte über den Kopf geschlagen werden, um einen geladenen Begriff auszuwählen und alle zu verwirren.

— jpmc26

In MVP ersetzt der Presenter den MVC-Controller. Der Unterschied zwischen den beiden besteht darin, dass der Präsentator die Ansicht direkt bearbeitet. Es wurde für UI-Frameworks entwickelt, die in erster Linie ereignisgesteuert sind (wie Windows Forms), ohne dass umfangreiche Datenbindungen unterstützt werden, die das MVVM-Muster unterstützen (wie WPF). Andernfalls würde ein Großteil der Logik zum Verwalten des Ansichtsstatus und zum Aktualisieren des Hintergrundmodells in der Ansicht selbst liegen.

— Michael Brown
quelle