Model-View-Controller (MVC)

Das Model View Controller Pattern (MVC) ist mittlerweile so etwas wie ein Heilversprechen für Fullstack-Framework-Entwickler geworden. Ähnlich wie beim griechischen Essen erlangt man nach einer gewissen Zeit den Zustand der absoluten Füllung. Es wird einfach als gegeben hingenommen, dass die Nutzung des MVC-Patterns die Lösung all unserer Probleme in der Entwicklung von Web-Anwendungen ist.

MVC – Bitte, was?

Für alle, die noch nicht wissen, was MVC überhaupt ist, kommt hier nun eine kurze Erklärung.

Um die Übersicht über eine Web-Anwendung zu behalten, kann dieses einfach in drei Komponenten geteilt werden:

Das M steht für Model (Modell)

Dieser Teil ist für die Geschäftslogik zuständig und verwaltet den Zustand von Objekten. Zumeist passiert hier die Kommunikation mit der Datenbank. Beispielsweise haben wir auf unserer Webseite eine TYPO3 Seminar-Extension entwickelt, in der es ein Seminar-Modell gibt, das neue Seminare in der Datenbank anlegt, die Daten aktualisiert und ausliest.

Das V steht für View (Ansicht)

Dieser Teil ist einfach zu verstehen und wahrscheinlich kann sich schon jeder vorstellen, wozu dieser Teil dient. Natürlich: für die Darstellung der Daten des Modells. Allerdings ist das Modell im Normalfall nicht direkt mit der View verbunden. Dafür gibt es den Controller.

Das C steht für Controller (Steuerung)

Der Controller steht zwischen Model und View und ist grob gesagt für die Datenmanipulation zuständig. Die View wird durch Updates vom Controller gefüllt mit Daten, die aus einem oder mehreren Models kommen.

Vorteile

Vorteile finden sich zum einen in der Möglichkeit, dass ein und dasselbe Datenmodell in mehreren Ansichten repräsentiert werden kann. Des Weiteren sind alle Ansichten, die sich auf ein Modell beziehen, automatisch synchronisiert und es können Bedienelemente beliebig vertauscht werden. Außerdem ist es ohne Weiteres möglich auf einem vorhandenen Modell einen neuen View zu implementieren. Dadurch ist ein solches System nahezu beliebig skalierbar.

Wenn man die MVC-Komponenten besonders lose koppeln möchte, bietet sich eine reine Broadcast-Kommunikation mittels eines Message Bus an. Vom Benutzer abgesehen, der stets explizit mit dem System kommuniziert, erfolgt jede Kommunikation per Broadcast-Nachricht: Ein Sender schickt Nachrichten an beliebig viele, dem Sender zu Beginn in der Regel noch unbekannte Empfänger. Da die Empfänger nicht direkt (d. h. per Unicast-Nachricht) beim Sender weitere Details erfragen können, müssen die Sender mit jeder Nachricht alle notwendigen Detail-Informationen mitschicken. Beliebige Module können als Nachrichten-Empfänger definiert werden, ohne dass der jeweilige Sender modifiziert werden müsste.

Nachteile

Ein Nachteil besteht darin, dass der Zugriff mehrerer Views auf ein Modell schnell zu einer hohen Komplexität führen kann und sich dadurch fehlerhafte Stellen in der Web-Anwendung schwerer ausfindig machen lassen. Des Weiteren kann man teilweise von einem ineffizienten Datenzugriff innerhalb eines Views sprechen, da immer noch ein Objekt dazwischengeschaltet ist. Auch die starke Abhängigkeit zwischen Model und Controller kann als Nachteil interpretiert werden.

Fazit

MVC ist aus der heutigen Web-Entwicklung nicht wegzudenken. Klar hat jedes Pattern seine Vor – und Nachteile. Aber entscheidend ist, dass man sich für das konkrete Problem das richtige Pattern raussucht. Möchtest Du z.B. beim MVC die Nachteile nicht in Kauf nehmen, bietet das MVVM hier eine alternative Lösung an. Es ist extrem nützlich, wenn man in größeren Teams arbeitet. Die Designer können eine Oberfläche entwerfen, während die Programmierer an Models und View-Models arbeiten. Wenn die Oberfläche fertig ist, kann sie ausgetauscht werden. Es gibt auch noch weitere Vorteile beim Testen. Das MVVM-Pattern zeichnet sich auch durch eine relativ übersichtliche Projektstruktur aus und ist auf jeden Fall eine Überlegung wert.