MVP und Geschichte

MVP(steht für „Model-Viewer-Presenter“) ist eine Ableitung des Patterns MVC(„Model-Viewer-Controller“), welches sog. Software-Entwurfsmuster sind.
MVC (und abgeleitete Konzepte) wurden entworfen, um Programmierern die Trennung von Daten-schichten zu ermöglichen. Bei MVP/C spricht man von einer Kontrollierenden, einer Modellierenden und einer Anzeigenden Datenschicht. Diese Daten-schichten werden meist durch Klassen(OOP, „Object orientated programming“) in verschiedenen Dateien aufgefunden. MVP (oder MVC) werden genutzt, um Wartungen, Tests, Wiederverwendbarkeit und Austauschbarkeit zwischen den einzelnen Schichten zu vereinfachen und zu ermöglichen.

Geschichte von MVP

1990 wurde dies erstmals durch Microsoft und Taligent verwendet und dadurch ins Leben gerufen. 2004 formulierte Martin Fowler dies jedoch nach seinem Verständnis. Seine Definition ist heute ausschlaggebend.

MVP im Kern

MVP ist in folgende Schichten unterteilt:

  • Das Modell - model
  • Die Anzeige - viewer
  • Der Präsentator - presenter

MVP besteht aus diesen drei Schichten. Dabei ist zu beachten, dass sich model und viewer sich nicht kennen.

Modell

Das Modell stellt - wie der Name schon sagt - das Datenmodell dar. Als solches beinhaltet es alle darzustellenden Daten, sowie bei Bedarf auch die Geschäftslogik. Das Model besteht streng genommen aus ebenfalls zwei Bestandteilen. Einer davon ist das eigentliche Datenmodell und das andere die Schnittstelle (Interface), die vom Presenter angesprochen werden kann (dazu unten mehr).

Einer dieser Ausnahmen wäre zum Beispiel, dass der Presenter nicht auf eine Datenbank zugreifen soll. Dies kann das Modell dann machen. So würde ein Teil der sog. „Geschäftslogik“ auf das Modell übertragen werden.

Anzeige

Die Anzeiger( jetzt „View“ genannt) zeigt lediglich Daten oder Benutzeraktionen an. View kennt weder Presenter noch dass Modell - dass heißt auch, dass View nichts vom Modell manipulieren kann - obwohl es auch aus zwei Schichten besteht: Der reinen Anzeige und dem Interface zum Presenter.

Presenter/ Präsentator

Der Präsentator (nun auch Presenter genannt) ist das Herzstück des ganzen Konzepts. Er stellt das Bindestück zur View und dem Modell dar. Er steuert alle Abläufe der Komponenten, kann die Geschäftslogik enthalten und stellt sicher, dass alle Änderungen am Modell an View übertragen wird und Umgekehrt. Dies macht der Presenter durch die Interfaces, die in View und dem Modell enthalten sind. Diese Interfaces sorgen dafür, dass der Presenter weiß, wie jede der anderen Komponenten aussieht und dass der Presenter sich mit jeder Komponente verbinden kann, die sich an diese Schnittstellen hält.

Interfaces/Schnittstellen

Die oben öfter erwähnten Schnittstellen sind anders als vielleicht vermutet KEINE Bestandteile der Schichten. Vielmehr stellen die Schnittstellen ein Interface zu Verfügung, damit Presenter darauf zugreifen kann. Dieses Interface schreibt vor, wie eine Schicht auszusehen hat und gibt „Standard“-Methoden vor, über die Kommuniziert werden. Die Komponente wird also - Programmiertechnisch - vom Interface abgeleitet, damit etwas Valides entstehen kann, womit der Presenter umgehen kann. Dieses Interface ist dennoch nicht Vorgeschrieben.

Ein kleines Beispiel, um zu zeigen wie man etwas mit MVP mit Interface verwirklichen könnte: Das Interface vom View, auf dass der Presenter zugreift verlangt für einen Datenbankeintrag 3 Parameter: PLZ, Ort, Name. Dem Programmierer wird innerhalb des Moduls nicht vorgeschrieben, dass er die Daten nach einem bestimmten Prinzip verarbeiten, oder entgegen nehmen, muss. Er kann theoretisch alles mit diesen Daten anfangen, was er will…

<?php
  interface view
  {
    protected viewNavi(array $links);
    protected viewContent(string $con);
    protected viewHead(string $image, string $cssFile, string $headCon);
  }
?>

Notwendigkeit

Natürlich ließe sich dass oben genannte Beispiel auch ohne Interfaces mit den anderen Komponenten verbinden. Aber dies würde dem Prinzip MVP entgegenlaufen - der Austauschbarkeit von Komponenten und der Wiederverwendbarkeit eines Presenters mit mehreren unterschiedlichen Views bzw. Modells.

Der Programmierer könnte natürlich genauso im Presenter voraussetzen, dass dieser sich direkt mit einem Model vom Typ A verbindet. In diesem Fall entfällt die zusätzliche Erstellung eines Interfaces, jedoch kann der Presenter nur genau für diesen einen Typ von Model verwendet werden. Die Verwendung eines Interfaces führt dazu, dass der Presenter nur vorschreibt, dass ein Model, welches sich mit ihm verbinden will, sich an bestimmte „Regeln“ halten muss. Damit könnte sich ein Model vom Typ A, B und C gleichermaßen mit demselben Presenter verbinden, sofern sie sich an die „Regeln“ halten.

Man sollte also je nach Projektbedarf überlegen, was genau man mit Hilfe von MVP umsetzen will und ob man sich für das aktuelle Projekt zu 100 % an das MVP-Konstrukt halten muss. Eventuell ist jedoch der Nutzen, den man durch die Verwendung von Interfaces hat höher als der Aufwand für deren Implementierung.

Beziehungen