© saicle/Shutterstock.com
Was wirklich hinter dem Model View Controller steckt

Was wirklich hinter dem Model View Controller steckt


Model View Controller ist das vielleicht bekannteste Entwurfsmuster, da es in nahezu jedem Webframework zum Einsatz kommt. Aber können Sie aus dem Stand heraus eine griffige Definition von MVC liefern, und stimmt sie auch mit Ihren Kollegen überein? In der Tat ist MVC ein Muster, das häufig falsch verstanden wird. Höchste Zeit also, mehr Licht ins Dunkel zu bringen.

Fast alle aktuellen PHP-Frameworks (und das sind sehr, sehr viele) sind MVC-Frameworks. Das sagen sie zumindest. Werfen Sie mal einen Blick in die Dokumentation Ihres bevorzugten Frameworks und lesen Sie die Definition von MVC nach. In den meisten Fällen werden sie nur wenig verwertbare Informationen finden. Auch Wikipedia hilft hier nicht wirklich weiter: „Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht“, heißt es da unter [1].

Das ist, wenn wir mal ganz ehrlich sind, ein Gemeinplatz, der schon fast eines politischen Wahlprogramms würdig wäre: Änderbarkeit, Erweiterbarkeit und Wiederverwendung, das ist es doch, wovon die IT-Welt seit dreißig Jahren redet. Und es war nicht die objektorientierte Programmierung, das gepriesene Allheilmittel, die uns alle diese ja durchaus erstrebenswerten Eigenschaften versprach? Was genau hat es also mit MVC tatsächlich auf sich?

Um Model View Controller zu verstehen, muss man eine kleine Zeitreise ins Jahr 1979 unternehmen. Zu dieser Zeit arbeitete der Norweger Trygve Reenskaug in Palo Alto an grafischen Bedienoberflächen. Zum Einsatz kam Smalltalk, eine der ersten objektorientierten Programmiersprachen. Ziel war es, die Benutzerinteraktion, insbesondere die Ansicht und das Editieren von Daten, sinnvoll abzubilden. Mit der Ausbreitung der grafischen Benutzeroberflächen wurden damals die so genannten Multiple Document Interfaces populär. Benutzer konnten dabei mehrere Fenster öffnen, die mitunter die gleiche Information auf unterschiedliche Art und Weise präsentieren. MVC tritt an, die Synchronisation zwischen diesen unterschiedlichen Präsentationen oder Sichten zu ermöglichen. Oft müssen auch mehrere Elemente einer Bedienoberfläche innerhalb eines Fensters synchronisiert werden.

MVC besteht aus den drei Komponenten Model, View und Controller. Trygve Reenskaug hat einmal gesagt, dass es der schwierigste Teil seiner Arbeit an MVC war, gute Namen für die einzelnen Komponenten zu finden.

Das Model

Grundlage für die Präsentation sind Daten, die im Model gehalten werden. Das Model ist dabei als Geschäftsobjekt zu verstehen und nicht als verantwortlich für den Datenzugriff. Im ursprünglichen MVC-Muster werden alle Komponenten beim Aufbau eines Fensters erzeugt und miteinander verdrahtet. Da PHP-basierte Webanwendungen für jeden Request die Objekte neu aufbauen müssen, werden Modelle hier gerne als für den Datenzugriff selbst verantwortlich gesehen. Das ist falsch, denn im ursprünglichen MVC-Entwurfsmuster hat das Model rein gar nichts mit Datenzugriff zu tun. SQL-Code hat dort also nichts zu suchen.

An ein Model können mehrere Sichten (Views) angehängt werden. Diese holen sich die für sie relevanten Daten aus dem Model und bereiten sie optisch auf. In Webanwendungen bedeutet das im Normalfall das Erzeugen von HTML-Code, deshalb werden Views oft mit Template Engines gleichgesetzt. Das ist falsch, denn MVC sagt rein gar nichts darüber aus, wie eine Ansicht zusammengebaut wird. Es mag sein, dass eine View eine Template Engine benutzt, aber in diesem Fall sollte Letztere ein Kollaborator sein, an den Arbeit delegiert wird. Eine View ist damit eher als ein Adapter zwischen dem Model und dem eigentlichen Rendering-Code zu sehen.

Wie können wir nun dafür sorgen, dass sich mehrere an ein Model angehängte Views automatisch synchronisieren, wenn sich das Model ändert?

Subject Observer

Dieses Problem wird durch das Subject-Observer-Entwurfsmuster gelöst. Dieses Muster muss man unbedingt verstanden haben, um auch MVC wirklich verstehen zu können. In der Tat ist es sogar so, dass Subject Observer gerade deshalb eine so hohe Bekanntheit erlangte, weil es ein Teil von MVC ist. Sehen wir uns also ein einfaches Beispiel an, um zu verstehen, welches Problem Subject Observer löst:

class Contract { public function terminate(...) {  // ...  } }

Wir betrachten eine interessante Methode einer Geschäftslogikklasse, beispielsweise die Methode zum Kündigen eines Vertrags. Da Kündigungen schlecht für das Business sind, möchte die Geschäftsführung immer dann direkt per SMS informiert werden, wenn ein Vertrag gekündigt wurde. Das ist zugegebenermaßen ein ziemlich konstruiertes Beispiel, aber es erfüll...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang