Der Presenter beinhaltet die Logik der Anwendung. Er ist die Verbindung zwischen dem Modell und der Sicht.
Model View Presenter (Abkürzung MVP; wörtlich etwa ‚Modell-Ansicht-Präsentierer‘) ist ein Entwurfsmuster in der Softwareentwicklung, das aus dem Model View Controller (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äsentierer (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.
MVP basiert wie MVC auch auf drei Komponenten: Dem Modell (model), der Ansicht (view) und dem Präsentierer (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äsentierer. Das Modell selbst kennt weder die Ansicht noch den Präsentierer.
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äsentierers noch auf das Modell. Sämtliche Steuerung der Ansicht erfolgt durch den Präsentierer.
Presenter
Der Präsentierer 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. Sie definieren den genauen Aufbau beider Schichten, und der Präsentierer 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 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äsentierer 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 der Präsentierer Daten über Klassen bereit, die der Ansicht und dem Modell bekannt sind. Der Präsentierer selbst sorgt nur noch für die Übertragung der Datenobjekte vom Modell zur Ansicht. Hierdurch entfällt weiterer Synchronisationsaufwand vom Präsentierer, da sich die Ansicht selbstä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äsentierer 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 Mock-Objekt ersetzt, wird so auch der Quelltext zur Synchronisation im Präsentierer geprüft. Es verbleibt in diesem Fall keine nennenswerte Logik mehr in der Ansicht. Dies verbessert also die Testbarkeit des Präsentierer 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.
