Model-View-Presenter (MVP) - Passive View
https://oer-informatik.de/gui_pattern_mvp
tl/dr; (ca. 7 min Lesezeit): Ist Model-View-Presenter nur ein anderer Name für MVC? Was unterscheidet einen Presenter von einer View? Es gibt zahllose Interpretationen dieser GUI-Pattern. Versuch einer Einordnung.
(Dieser Artikel ist Bestandteil einer Serie von Artikeln zu GUI-Pattern, in der MVC, MVVM und MVP voneinander abgegrenzt werden.)
Kernaspekte des Patterns
Das MVP-Pattern ist gekennzeichnet von:
kompletter Entkopplung zwischen View und Model
Kommunikation erfolgt immer über den Presenter, der als Mediator (ein Pattern) zwischen den beiden anderen Komponenten vermittelt
Nutzung v.a. in eventbasierten Frameworks mit asynchroner Aktualisierung von Komponenten.
Die Implementierung einer graphischen Oberfläche nach den GUI-Mustern (MVC/MVP/MVVM) wird von jedem modernen Framework anders realisiert. Zum Teil haben die Rollenzuweisungen, Abhängigkeiten und Nachrichtenflüsse nicht mehr viel mit dem zu tun, was man in ursprünglichen Definitionen MVC/MVP/MVVM zugesprochen hatte.
Auf dieser Seite wird versucht, die ursprünglichen Charakteristika des MVP-Patterns in der Spezialisierung Passive View herauszuarbeiten und gegen MVC abzugrenzen. Damit sollte es möglich sein, die Rollen des jeweiligen Frameworks einzuordnen.
Hintergrund / Probleme bei frühen MVC-Implementierungen
Historisch hatten sich in der MVC-Implementierung von Smalltalk eine Reihe von Probleme eingeschlichen:
- Zwischen Model und View bestand über das Observer-Pattern eine Abhängigkeit. Diese Abhängigkeit war zwar gering (lose Kopplung per Observer), kann sich aber negativ auf die Evolvierbarkeit und Testbarkeits des Codes auswirken.
- Der Austausch der View für verschiedene Plattformen war aufgrund dieser Abhängigkeit nicht optimal.
- Für Event-basierte Systeme hatte sich die ursprüngliche MVC-Architektur als nicht optimal herausgestellt.
Die Lösung damals war eine Anpassung im Nachrichenfluss und in den Zuständigkeiten, die heute noch bei AJAX-basierten Frameworks anzutreffen ist:
Rolle der View:
Die View ist lediglich eine Struktur von GUI-Komponenten (z.B. reines HTML über Template-Engines), sie enthält über den reinen Aufruf der Presenter Methoden hinaus keinerlei Logik. In einigen Frameworks kann die View Logik in Form von Javascript-Scripten enthalten, die jedoch im wesentlichen nur den Presenter-Aufruf vorbereiten.
In der Literatur finden sich auch Definitionen, die eine Observer-Beziehung zwischen View- und Model zulassen - zur schärferen Abgrenzung der Varianten wollen wir diese Fälle jedoch nicht betrachten.
Presenter
Hier wird auf das Verhalten des Users reagiert (das eigentliche Event-Handling). Sämtliche Änderungen am Model können über das Design-Pattern Command verpackt werden, um undo/redo zu ermöglichen. Der Presenter sucht eine geeignete View (z.B. das nötige HTML-Template), aktualisiert das Model, fügt die korrekten Daten in die View ein und sendet alles zusammen wieder an den Client.
Model
Die Komponente Model ist weitgehend identisch zu dem Model in MVC.
Weitere Realisierungen von MVP:
Realisierung über Interfaces
Um die Testbarkeit und Austauschbarkeit zu erhöhen können Model und View auch über Interfaces realisiert werden, die im Presenter referenziert werden. Hierdurch können leicht Mock-Objekte an Stelle der View oder des Model mit dem Presenter verknüpft und nur dieser isoliert getestet werden (Unittests).
Passive View
Die oben geschilderte Variante von MVP wird häufig als passive View bezeichnet, da die gesamte von der View benötigte Logik (zur Konfiguration der GUI-Komponenten) im Presenter abgebildet ist. Die View selbst ist weitestgehend frei von Logik und aktiven Komponenten - daher der Name. Sie hat selbst auch keinerlei Beziehung zum Model. Diese Form ist besonders gut testbar.
Supervising Controller (nach Martin Fowler)
In einer zweiten Variante enthält die View Logik für grundlegende, einfache Konfiguration der GUI-Komponenten - etwa das Datenbinding mit dem Model. Der Presenter ist für komplexere Aufgaben zuständig. Die oben genannte Entkopplung View/Model findet so nicht statt, dadurch werden schlankere Presenter (Controller) möglich. Da hierbei die Abgrenzung zu den anderen Pattern schwerer fällt, haben wir das Augenmerk auf die Passive View gelegt.
Unterschiede zu anderen GUI-Mustern:
Bei MVC kann jede GUI-Komponente (Widget, also im Extremfall jeder Button etc.) über ein eigenes View/Controller-Paar verfügen. Bei MVP gibt es nur einen Presenter (auf Form-Ebene), der für die Benutzereingaben aller Elemente verantwortlich ist und Anfragen ggf. an weitere Presenter weiterreicht.
Es gibt keinerlei Abhängigkeiten zwischen Model und View. Die Kommunikation zwischen diesen beiden Komponenten verläuft immer über den Presenter.
Im Fall eines Supervising Controllers enthält die View deutlich mehr Logik zur Konfiguration als eine View des MVC-Pattern, bei der Variante Passive View enthält die View hingegen keinerlei Logik.
Zum besseren Verständnis und den unterschieden der einzelnen GUI-Pattern sollten auch die Artikel der anderen Pattern gelesen werden:
Das Model-View-Controller-Pattern (MVC): Der Ursprung aller modernen GUI-Pattern
Das Model-View-Presenter-Pattern (MVP): Häufig in AJAX-basierten Frameworks anzutreffendes, komplett entkoppeltes GUI-Pattern
Das Model-View-ViewModel-Pattern (MVVM): Realsierung in vielen modernen Desktop-App Frameworks
Links und weitere Informationen
Grundlagenpapier zu MVP von Mike Potel (Taligent / IBM):
Grundlagenpapier des Designteams von Dolphin Smalltalk MVP Andy Bower, Blair McGlashan (Object Arts Ltd.):
Quellen und offene Ressourcen (OER)
Die Ursprungstexte (als Markdown), Grafiken und zugrunde liegende Diagrammquelltexte finden sich (soweit möglich in weiterbearbeitbarer Form) in folgendem git-Repository:
https://gitlab.com/oer-informatik/design-pattern/gui-pattern.
Sofern nicht explizit anderweitig angegeben sind sie zur Nutzung als Open Education Resource (OER) unter Namensnennung (H. Stein, oer-informatik.de) freigegeben gemäß der Creative Commons Namensnennung 4.0 International Lizenz (CC BY 4.0).
