Model View Presenter

Model-View-Presenter (Abkürzung: MVP; wörtlich etwa ‚Modell-Ansicht-Präsentator‘) ist ein Entwurfsmuster in der Softwareentwicklung, das aus dem Model-View-Controller (Abkürzung: MVC) hervorgegangen ist. Es beschreibt einen neuartigen Ansatz, um das Modell (engl. Model) und die Ansicht (engl. View) komplett voneinander zu trennen und über einen Präsentator (engl. Presenter) zu verbinden. Dabei steht neben einer deutlich verbesserten Testbarkeit auch die strengere Trennung der einzelnen Komponenten im Gegensatz zu MVC im Vordergrund.

Erstmals eingesetzt und genannt wurde dieses Entwurfsmuster in den 1990er-Jahren von IBM und Taligent. Martin Fowler formulierte jedoch im Jahre 2004 Model-View-Presenter nach seinem Verständnis. Seine Definition ist heute ausschlaggebend.

Definition

MVP basiert wie MVC auch auf drei Komponenten:

• Modell – Model
• Ansicht – View
• Präsentator – Presenter

Model

Das Modell stellt die Logik der Ansicht dar. Dies kann auch die Geschäftslogik sein. Über das Modell muss jedoch alle Funktionalität erreichbar sein, um die Ansicht betreiben zu können. Die Steuerung des Modells erfolgt allein vom Präsentator. Das Modell selbst kennt weder die Ansicht noch den Präsentator.

View

Die Ansicht enthält keinerlei steuernde Logik und ist nur allein für die Darstellung und die Ein- und Ausgaben zuständig. Sie erhält weder Zugriff auf die Funktionalität des Präsentators noch auf das Modell. Sämtliche Steuerung der Ansicht erfolgt vom Präsentator.

Presenter

Der Präsentator ist das Bindeglied zwischen Modell und Ansicht. Er steuert die logischen Abläufe zwischen den beiden anderen Schichten und sorgt dafür, dass die Ansicht ihre Funktionalität erfüllen kann.

Damit MVP seine eigentlichen Vorteile gegenüber MVC entfalten kann, werden für Modell und Ansicht jeweils Schnittstellen (engl. Interfaces) verwendet. Die Schnittstellen definieren den genauen Aufbau beider Schichten und der Präsentator verknüpft lediglich die Schnittstellen miteinander. Dies gewährleistet die vollständige Austausch- und Wiederverwertbarkeit des Modells und der Ansicht. Resultierend aus der Austauschbarkeit der Ansicht lässt sich so vor allem ein Double (französisch für „Doppelgänger“) für die Ansicht verwenden, um die Funktionalität aus Perspektive der Oberfläche mit sogenannten Modultests (engl. unit tests) zu prüfen.

Im Jahre 2006 entschied sich Martin Fowler, aufgrund von Erkenntnissen bei der praktischen Anwendung von MVP, das ursprüngliche Entwurfsmuster in zwei differenzierte Muster aufzuteilen^[1]: Supervising Controller und Passive View. Beide Muster unterscheiden sich hinsichtlich ihrer Testbarkeit und ihrer Handhabung.

Supervising Controller

Supervising Controller (wörtlich etwa ‚Überwachende „Steuerung“) ist ein Entwurfsmuster, das aus der ursprünglichen Variante von MVP hervorgegangen ist und von Martin Fowler definiert wurde. Hierbei übernimmt die Ansicht möglichst alle Aufgaben zur Datensynchronisation, während sich der Präsentator um alle anderen Abläufe zwischen Modell und Ansicht kümmert. Um die Synchronisation möglichst zu vereinfachen, kann auf Datenbindungen (engl. data bindings) zurückgegriffen werden. Dabei stellt das Modell Daten über Klassen bereit, die der Ansicht und dem Modell bekannt sind. Der Präsentator selbst sorgt nur noch für die Übertragung der Datenobjekte vom Modell zur Ansicht. Hierdurch entfällt weiterer Synchronisationsaufwand vom Präsentator, da sich die Ansicht selbstständig über die Datenobjekte synchronisiert. Das Modell kann seinerseits ebenfalls über die Datenobjekte auf innerhalb der Ansicht veränderte Daten zugreifen.

Passive View

Passive View (wörtlich etwa „Untätige Ansicht“) ist ein Entwurfsmuster, das aus der ursprünglichen Variante von MVP hervorgegangen ist und von Martin Fowler definiert wurde. Im Gegensatz zum Supervising Controller existiert keine Verbindung über ein Datenobjekt zwischen Modell und Ansicht. Dies trägt dazu bei, dass der Präsentator jegliche Datensynchronisation zwischen Modell und Ansicht selbst durchführen muss. Das Ergebnis dabei ist, dass die Ansicht nur einfachste Logik zur Anzeige beinhaltet und keine Logik zur Synchronisation von Daten. Dadurch wird der Quelltext der Ansicht äußerst vereinfacht, anders als dies beim Supervising Controller der Fall ist.

Unterschiede

In der Passive View verbessert sich die Testbarkeit gegenüber dem Supervising Controller, da nur noch einfachster Quellcode zur Ein- und Ausgabe in der Ansicht vorhanden ist. Wird die Ansicht bei Tests durch ein Double ersetzt, wird so auch der Quelltext zur Synchronisation im Präsentator geprüft. Es verbleibt in diesem Fall keine nennenswerte Logik mehr in der Ansicht. Dies verbessert also die Testbarkeit des Präsentators und des Modells entscheidend.

Im Gegensatz dazu bietet der Supervising Controller den Vorteil einer vereinfachten Handhabung. Durch die Datensynchronisation über Datenbindungen zwischen Modell und Ansicht wird der Synchronisationsaufwand wesentlich verringert, welches insgesamt weniger Quelltext erforderlich macht, als es bei der Passive View der Fall ist.

Referenzen

1. ↑ Retirement note for Model View Presenter Pattern (englisch)

Weblinks

• Model-View-Presenter Definition von Taligent (englisch; PDF-Datei; 154 kB)
• Herkunft und Funktionsweise von Model-View-Presenter (englisch)
• Supervising Controller (englisch)
• Passive View (englisch)