Der Klassiker unter den Frontend-Designs ist das Model-View-Controller-Pattern (MVC-Pattern, s. Abb. 1). Die Aufteilung in die drei Klassen entspricht unmittelbar der Aufteilung in die drei Aufgabenbereiche. Der Controller enthält die Logik zur Steuerung und hat direkte Abhängigkeiten zu View und Modell. Für den Fall einer Benutzerinteraktion gibt es zudem eine lose Kopplung vom View zum Controller. Diese kann zum Beispiel über ein Observer oder ein Event Bus Pattern realisiert werden. Eine direkte Abhängigkeit des Views zum Controller – zum Beispiel in Form einer direkten Referenz – gibt es nicht. Wird der Controller über eine Benutzerinteraktion informiert, kann er geeignet darauf reagieren. Durch Aufruf der Geschäftslogik können Daten im Model geändert werden. Hier liegt schon die erste Fehlerquelle verborgen. Der Controller sollte die Daten im Model nicht direkt ändern, da dies bereits eine Geschäftsentscheidung wäre. Vielmehr ist er ein Bindeglied zwischen Geschäftslogik und User Interface. Er ruft lediglich die zum Benutzerevent zugehörige Geschäftslogik auf und überlässt dieser die Entscheidung über Datenänderungen. Die direkte Manipulation der Daten im Model führt oft zu unerwünschten Seiteneffekten in der Fachlichen Modellierung. Mehrere Aufrufe auf dem Model in einer Anfrage oder das direkte Lesen und Schreiben von Daten im Model sind Symptome dafür, dass der Controller sich in die Geschäftslogik einmischt.

Desweiteren ist er für die Navigation zwischen verschiedenen Views verantwortlich. Er kann eine View anpassen, austauschen oder zu einem anderen Controller wechseln. Um Models nicht zwischen den Controllern herumreichen zu müssen, steuert ein Controller alle Views des gleichen Models.

View n:1 Controller

Wie bereits beschrieben, ist das Model vollständig unabhängig von View und Controller. Damit ist auch die Geschäftslogik unabhängig von technischen Implementierungen und kann separat ausmodelliert und getestet werden. Die View ist hingegen abhängig vom Model. Sie kann Daten direkt aus dem Model auslesen, um diese anzuzeigen und Benutzereingaben direkt ins Model zu schreiben. Wenn sich Daten im Model ändern, muss die View über die Änderung informiert werden, um sich anzupassen. Dies kann durch einen Hinweis des Controllers geschehen, dass Daten veraltet sind und neu geladen werden müssen. Eine andere Möglichkeit ist eine lose Kopplung des Models an die View, z. B. in Form eines Observer-Patterns. Auf diese Weise wird eine View über jede Änderung im Model informiert und kann sich entsprechend aktualisieren. Der Datenfluss findet im MVC-Pattern direkt zwischen Model und View statt. Folglich muss die View Logik zum technischen Validieren und Konvertieren von Daten implementieren. In der Praxis bieten viele Frontend-Frameworks ein Data Binding zwischen Model und View an, welches auch diese Funktionalitäten abdeckt. Fachliche Validierungen sind hingegen Teil der Geschäftslogik. Durch den User ausgelöste Änderungen an der View – wie zum Beispiel das Einblenden zusätzlicher Felder nach Betätigung eines Häkchens oder das Einblenden eines Untermenüs – können von der View selbst geregelt werden.

Bei serverseitigen Web-Technologien wie JSPs oder Rails entsteht die lose Kopplung zwischen View und Controller bereits auf technischer Ebene durch das Http-Protokoll. Zudem ist es oft nicht sinnvoll, eine durch den Benutzer ausgelöste Änderung in der View dem Server zu melden, wenn dieser in der Folge nichts Weiteres tut, außer der View zu sagen, wie sie sich anpassen soll. In dem Fall ist es sicherlich naheliegend, die Benutzerinteraktion direkt clientseitig zum Beispiel via JavaScript zu behandeln. Um das Ziel der Wartbarkeit zu erhalten, sollte die Implementierung von Geschäftslogik in der View aber unbedingt vermieden werden.

Eine Schwäche des MVC Pattern ist die Mächtigkeit der View. Durch den direkten Zugriff auf das Model kommt oft (unbewusst) eine Menge Logik mit in die View. Diese ist dann nur sehr schlecht test- und wiederverwendbar, weil die Logik meist mit den optischen Elementen verwoben ist. Neben View-interner Logik, Validierung und Konvertierung landet außerdem oft Geschäftslogik in der View. Zudem bleibt der Controller oft sehr passiv, wenn die View Geschäftslogik auf dem Model direkt aufrufen kann und beschränkt sich auf die Navigation. Bei gewachsenen Projekten verschwimmen so die Grenzen der Aufgabenbereiche. Im schlimmsten Fall wird die Geschäftslogik über Model, View und Controller verteilt und die Komponenten verwachsen miteinander.

Im Gegensatz dazu versucht das Model-View-Presenter-Pattern (MVP, s. Abb. 2) die View "dumm" zu halten. Sie soll so wenig Logik wie möglich enthalten. Dies macht die Logik leichter testbar und die optischen Elemente besser wiederverwendbar. Zu diesem Zweck wird alle Logik vollständig aus der View entfernt und der Zugriff auf das Model untersagt. Da diese Logik sehr view-spezifisch ist, erscheint es nun aber wenig sinnvoll, diese in einen Controller zu verlegen, der sich an einem Model orientiert und mehrere Views bedient. Stattdessen übernimmt hier ein so genannter Presenter die Steuerungsaufgaben. Jeder Presenter ist verantwortlich für genau eine View. Wie der Controller ist er verantwortlich für die Navigation und Verarbeitung von Benutzerinteraktionen. Da die View jedoch unabhängig vom Model implementiert wird, muss der Presenter die Daten selbst aus dem Model entnehmen und der View in passend konvertierter Form bereitstellen. Hatte im MVC-Pattern die View eine lose Kopplung zum Model, um auf eine Änderung der Daten zu reagieren, so besteht diese lose Kopplung im MVP-Pattern zwischen Presenter und Model. Registriert der Presenter eine Änderung der Daten, ist er dafür verantwortlich, die Daten aufzubereiten und die View zu aktualisieren.

View 1:1 Presenter

In die andere Richtung hat jede View ihre eigene Presenter-Instanz. Auch wenn es im MVP-Pattern durchaus möglich ist, Presenter und View direkt gegenseitig voneinander abhängig zu implementieren, ist es ratsam, dem Presenter ein Interface vorzuschalten (s. Abb. 3). Dieses enthält dann alle Benutzerinteraktionen, welche die View an den Presenter weiterreichen kann. Dadurch kann die View dann unabhängig vom Presenter implementiert und besser wiederverwendet werden. Da die View keine Kenntnis vom Model hat, bekommt der Presenter im Fall eines Aufrufs die rohen Benutzereingaben und muss diese technisch validieren und konvertieren bevor sie der Geschäftslogik übergeben werden können.

Die große Stärke des MVP-Patterns ist die Unabhängigkeit zwischen View und Model, welche eine klare Trennung der Aufgabenbereiche ermöglicht. Auf der anderen Seite bringen viele Frontend-Frameworks – wie z. B. Wicket oder Vaadin – ein gutes Data Binding zwischen View und Model mit. Auf eine komplett passive View ohne Kenntnis des Models zu setzen heißt, hierauf verzichten zu müssen. Dies bedeutet einen unverhältnismäßig höheren Aufwand für den Entwickler, der sich um vieles selbst kümmern muss, was das Framework mit dem Data Binding bereits mitbringt. Außerdem kann der Presenter vor lauter Vermittlungslogik zwischen View- und Modelfeldern schnell unübersichtlich groß werden, ohne dabei schwerwiegende Logik zu enthalten.

Für dieses Problem gibt es eine Art Kompromiss zwischen einer komplett passiven View auf der einen und einer unklaren Aufgabentrennung auf der anderen Seite. Das MVP-Supervising-Controller-Pattern (s. Abb.4) hebt die strikte Trennung zwischen Model und View im Fall von Data Binding auf. Das Model wird vom Presenter direkt der View übergeben und per Data Binding gebunden. Hierbei ist es wichtig, dass das Model vom View nach der Initialisierung nicht für die komplette View verfügbar gemacht wird, sondern der View ausschließlich zur Initialisierung des Data Bindings zur Verfügung steht. Somit ist nach der Initialisierung jede Operation außerhalb des Data Bindings nur noch über den Presenter möglich.

Auf diese Weise verschwindet die Validierungs- und Konvertierungslogik wieder im Data Binding. Diese kann normalerweise relativ einfach über Integrationstests zwischen View und Model getestet werden. Auf der anderen Seite bleibt immer noch eine von Logik befreite View.

Ein weiterer Nachteil des MVP-Patterns ist die schwierige Wiederverwendbarkeit der Presenter-Funktionen. Soll zum Beispiel ein Wert auf mehreren Views angezeigt werden oder sollen mehrere Views auf dem gleichen Model arbeiten, muss unter Umständen viel Code dupliziert oder in Helferklassen ausgelagert werden. Das Model-View-ViewModel-Pattern (MVVM, s. Abb. 5) adressiert genau dieses Problem.

Im Gegensatz zu einem Presenter ist ein ViewModel nur noch für einen einzigen oder eine kleine Gruppe von Werten und Benutzer-Interaktionen zuständig und kapselt alleine deren Logik. Dabei wird neben dem Model auch jeder anzuzeigende Wert direkt gehalten. Dieser wird dann von der View über ein Observer-Pattern beobachtet und abgegriffen. In der Praxis besteht hier ein Data Binding zwischen der View und dem ViewModel. Bei diesem ViewModel können sich jetzt beliebig viele Views anmelden und somit alle den gleichen aktuellen Wert anzeigen. Um alle Felder anzeigen zu können wird eine View unter Umständen mehrere ViewModels beobachten.

View n:m ViewModel

Ein kleines Beispiel (s. Abb. 6). Ein Model Warenkorb enthält Produkte mit einem Preis und bietet eine Methode, um den WarenkorbWert zu ermitteln. Das ViewModel WarenkorbWertViewModel meldet sich als Observer beim Model an und wird benachrichtigt, wann immer die Liste der Produkte verändert wird. In dem Fall holt es sich den neuen WarenkorbWert und aktualisiert das entsprechende Feld. Dieses wiederrum ist per Data Binding oder ebenfalls über ein Observer-Pattern mit der View verbunden. Ändert sich also die Liste der Produkte im Model, wird sofort ein neuer WarenkorbWert errechnet und unmittelbar aktuell auf allen registrierten Views angezeigt.

Im Gegensatz zu einem Presenter oder einem Controller präpariert ein ViewModel nur Werte und hat keine Kenntnis von den Views, für welche die Werte aufbereitet werden. Die View ist selbstständig dafür zuständig, sich den aktuellen Wert zu holen und auf Kommando zu aktualisieren – ohne jedoch Anwendungslogik zu beinhalten oder auf das Model selbst zuzugreifen. Data Binding oder das Observer-Pattern synchronisiert den Wert im View mit dem im ViewModel und konvertiert und validiert diesen nach Bedarf. Auf diese Weise kann der WarenkorbWert auf der einen View als Zahl (z. B. 200,00 €) und auf der anderen konvertiert zu einem Wort (z. B. "Zweihundert Euro") dargestellt werden. Das ViewModel selbst kümmert sich um die Synchronisierung mit dem Model und arbeitet eingehende Benutzerinteraktionen ab.

Da das ViewModel nichts von irgendwelchen Views weiß und eigentlich nur seine Beobachter über eine Veränderung informiert, besteht natürlich auch die Möglichkeit, dass sich ein anderes ViewModel registriert. Im Beispiel vom WarenkorbViewModel könnte sich zum Beispiel ein GesamtPreisViewModel registrieren, welches den Warenkorbwert inklusive der Versandkosten enthält. Dieses würde ebenfalls über eine Veränderung des WarenkorbWertes informiert werden und seinen Wert ebenfalls neu berechnen und diesen wiederum bei sich zur Verfügung stellen.

Eine Gefahr des MVVM-Patterns ist Unübersichtlichkeit. Es entstehen sehr viele ViewModels bei denen erstmal nicht klar ist, von welchen Views diese überhaupt verwendet werden. Insbesondere wenn ViewModels aufeinander aufbauen besteht die Gefahr, dass sehr aufwändig und im schlimmsten Fall zeitintensiv Werte berechnet werden, die schlussendlich nirgends angezeigt werden. Außerdem besteht die Gefahr, Kreise zu implementieren, welche endlos Werte neu berechnen. Ein solches Frontend-Design fordert dadurch etwas sorgfältigere Dokumentation, um Wildwuchs zu vermeiden. Dem gegenüber stehen kleine Klassen, hohe Wiederverwendbarkeit, klare Aufgabentrennung und gute Testbarkeit des Codes.