Skip to main content

MVC ist nicht OK!

Der Titel mag ein wenig kontrovers klingen, aber angesichts der sich in letzter Zeit häufenden Diskussionen zu dem Thema, scheint es Erklärungsbedarf zu geben. Was ist MVC, muss alles nach MVC konstruiert sein, oder macht das manchmal auch keinen Sinn? Diesen Fragen gehen wir auf den Grund.

Model View Controller

Unter MVC oder der Model View Controller-Architektur versteht man ein weithin bekanntes und teilweise als Allheilmittel wahrgenommenes Design Pattern für Softwaresysteme. Es hat seinen Ursprung in Smalltalk und stellt die Basis für praktisch alle bekannten UI-Frameworks dar. Das Prinzip ist einfach: Man trennt die drei primären Komponenten einer Anwendung, das Datenmodell (Model), die Darstellung (View) und die Ablauflogik (Controller) möglichst weit voneinander und lässt diese im Idealfall nur indirekt über Events miteinander kommunizieren.

Der vielleicht wichtigste Vorteil der dadurch erreicht wird ist, dass die drei Komponenten voneinander zeitlich unabhängig agieren können. Der Controller gibt Befehle an das Model weiter, wenn diese verarbeitet wurden, benachrichtigt dieses wiederum die View. Ohne dass das Programm währenddessen die Ausführung stoppen muss. Also die Grundlage für das Verhalten, das wir unter Multithreading/Multiprocessing verstehen.

OMG - Drupal ist ja gar nicht MVC!

Schon mehr als einmal wurde ich in Diskussionen zu diesem Thema hineingezogen. Es ist interessant, dass man das Fehlen einer MVC-Architektur gleich implizit als Qualitätsmangel betrachtet. Gehen wir einen Moment in uns und betrachten die Funktionsweise von HTTP/PHP Anwendungen im Zusammenhang mit dem im letzten Abschnitt erworbenen Wissen:

Wie viel Prozesse hat dein HTTP Request der über PHP verarbeitet wird im Durchschnitt? Richtig: Einen

Wie viele dieser Prozesse werden durcheinander, miteinander kommunizieren? Wieder richtig: Es ist verdammt leise.

Zugegeben, mit Websockets und bidirektionaler Kommunikation zwischen Server und Client sieht die Sache wieder anders aus, aber davon ist auch nicht die Rede. Solange sich also keine einsamkeitsbedingten Persönlichkeitsspaltungen unter PHP Prozessen entwickeln ist der Vorteil der temporalen Unabhängigkeit von MVC ziemlich obsolet.

Die meisten Leute die sich über das fehlen von MVC beschweren, meinen aber in Wirklichkeit auch gar nicht MVC, sondern schlicht und einfach die Trennung von Daten, Logik und Layout. Dafür gibt es aber das deutlich einfachere Layermodell, welches die Funktionsweise von Webseiten viel besser abbildet.

Der Controller fängt ein HTTP Request, wertet dieses aus, lädt die geforderten Daten aus dem Model und übergibt sie an die View um den HTML- Output zu rendern.

  • Die View wird sich niemals selbstständig Daten vom Model holen.
  • Das Model wird niemals die View über Veränderungen informieren.
  • Es werden niemals zwei Benutzeranfragen gleichzeitig verarbeitet.

MVC stellt vor allem das Werkzeug um Umständen Herr zu werden, die im besprochenen Anwendungsfall nicht auftreten können. Man bringt also unnötig komplexe und starre Strukturen in ein System, ohne die Vorteile derer nutzen zu können. Larry Garfield geht in einem schon relativ alten (2006) aber trotzdem gültigen Artikel auf die Drupal und MVC ein. Prädikat lesenswert!

OMFG - Drupal ist gar nicht OOP!

Diese Beschwerde kommt meistens von Leuten die Objektorientierung mit dem Property Access Operator ("->" in PHP) gleichsetzen. Es stimmt, "class" und "interface" kommen in Drupal verhältnismäßig selten vor. Vererbung und Polymorphie sind aber auch sehr starre Konstrukte, die spezifische Modifikationen von Komponenten oft schwer machen. Stattdessen wird das Decorator Pattern eingesetzt um eine höhere Flexibilität zu erreichen. Nur ohne "->", dafür aber auch mit weniger Code und Abhängigkeiten.

Im Prinzip sind Module, primär Singletons, die Decorator Interfaces implementieren, und selbst wiederum solche über module_invoke und module_invoke_all bereitstellen. "Drupal programming from an object-orientet Perspektive" auf drupal.org geht auf diese Konzepte sehr genau ein.

ZOMFG - Du meinst MVC und OOP sind Blödsinn?

Nichts liegt mir ferner. Es gibt genug Anwendungen von OOP in Drupal und es gibt noch viel mehr Anwendungsfälle, wo es Sinn machen würde und die mit der Zeit in Angriff genommen werden. Aber jedes Design Pattern hat einen bestimmten Zweck, und den sollte man genau kennen bevor man es einsetzt.

Drupal mag, wie jede Software, eine Menge konzeptionelle Schwächen haben, aber es wird zumindest versucht die zugrunde liegende Technologie (HTTP) und Sprache (PHP) mit all deren Stärken und Schwächen zu nutzen, anstatt Patterns zu implementieren die damit eigentlich nicht harmonieren.

Wird nicht veröffentlicht
  • Das Problem ist halt, dass MVC im Web-Bereich einen Bedeutungswandel durchgemacht hat: nicht mehr das austauschen von Events ist charakteristisch, sondern die klare Trennung von Präsentation, Daten und Steuerung. Das mag rein akademisch nicht ganz korrekt sein und eher dem erwähnten Layer-System entsprechen, aber in der Praxis wird das (leider?) synonym verwendet. Schlampig sind sie, diese Internet-Leute :-P

    Wenn also Django, Symfony, Ruby on Rails und andere sich selbst als MVC bezeichnen (und intern ihre Komponenten auch so benennen, z.B. "Model" in Django, "Controller" in Symfony), dann ist selbstverständlich auch Drupal MVC.

  • Wenn es nur um die Benennung ginge wäre es ja kein Problem. Aber es soll tatsächlich Leute geben die nicht fürs Web entwickeln (im Ernst!) sondern aus Bereichen kommen in denen "klassisches" MVC Sinn macht. Und wenn die Sachen auch noch gleich heißen, sind sie natürlich verleitet die selben Muster anzuwenden. Ich hatte schon das zweifelhafte Vergnügen daraus entstandene Monster im nachhinein warten zu müssen.

    "There are only two hard problems in Computer Science: cache invalidation and naming things." -- Phil Karlton*

    *Idee für Zitat dreist geklaut von Wolfgang Z.

  • Haha, super Beitrag!
    Sehe ich genauso. Erinnert mich an die Leute, die immer sagen "XY kann man nur in ABC bauen und alle anderen sind schlecht" :-)
    Es ist ja doch so, dass man mit 99% der Paradigmen auch ungefähr 99% der Probleme lösen kann...