MVC-Pattern im Web
Das MVC-Pattern gibt es schon seit dem 20. Jahrhundert. Publiziert wurde es in den 90er Jahren zusammen mit dem Buch “Design Patterns” u.a. von Erich Gamma. Damals bezog sich das Pattern noch auf GUI-basierte Programme, z.B. ein Texteditor.
Mit der Verbreitung des Web wurde dieses Pattern auch auf die Webwelt portiert. Obwohl das Pattern schon so lange bekannt ist, trifft man in der Entwicklerwelt trotzdem oft auf Menschen, denen das Muster nichts sagt. Mit diesem Beitrag möchte ich das Pattern aufarbeiten, um es in späteren Beiträgen (z.B. für das Zend Framework) als Grundlage gebrauchen zu können.
Um das Pattern zu verstehen, ist es am besten vorher zu erfahren, was die Abkürzung bedeutet. Das M steht für das Model, V für den View und das C für den Controller. Die Langversion lautet also Model-View-Controller Pattern. Nachfolgend werde ich die einzelnen Ebenen und deren Zusammenspiel erläutern.
Das Model
In allen drei Schichten muss man im Grunde etwas weiter ausholen, so auch beim Model. Das Model dient allgemein dazu die reale Welt – genauer gesagt Teile davon – in einer gewissen Form abzubilden. In der Softwareentwicklung wird dafür ein oder mehrere Diagramme des Problembereichs erstellt. Diese Diagramme dienen später als Plan, um die Objekte bzw. Datenstrukturen zu erstellen.
Diese Daten und ihre Strukturierung stellen das Model dar. Man könnte diese Ebene vereinfacht auch als Datenbehälter bezeichnen. Nehmen wir doch einfach ein konkretes Beispiel. Ich möchte mein Auto modellieren. Mich interessieren dabei die Marke, die PS Angabe und die Höchstgeschwindigkeit. Dazu erstelle ich eine Klasse “Auto” mit den Klassen-Attributen “marke”, “ps” und “maximalgeschwindigkeit”. Das Model ist nun fast fertig. Das einzige, was es noch benötigt sind sogenannte Getter- und Setter-Methoden. Diese brauchen wir, um einem Objekt der Klasse Auto Daten hinzufügen zu können und ebenfalls diese Daten wieder auszulesen.
Der View
Der View ist mitunter am einfachsten zu erklären. Er stellt die Sicht auf das Model dar. D.h. die Daten des Models werden hier auf dem Bildschirm visualisiert. In der Web-Welt ist es die (ausgelieferte) Webseite, die der Benutzer am Ende zu sehen bekommt. Zusätzlich ist der View die Schnittstelle zwischen System und Benutzer. Der Benutzer interagiert also auf der View-Ebene, z.B. durch Formulare oder durch das Klicken eines Links.
Der Controller
Der Controller ist als Steuerungseinheit zu verstehen. Der Idee nach wissen Model und View am Anfang nichts voneinander. Die Anfrage eines Clients (Web-Browser des Benutzers) an einen Server wird vom Controller entgegen genommen. Dieser Wertet die Anfrage aus.
Nehmen wir nochmals das Beispiel aus dem Model-Abschnitt. Der Benutzer möchte nun erfahren, welches Auto ich fahre und klickt entsprechend auf einen Link. Der Controller erkennt nun diese Anfrage und bereitet das Model auf. Dazu erstellt er ein Auto-Objekt und setzt die Daten auf “Suzuki”, “92″ und “180km/h”. Das Model ist damit gefüllt. Jetzt entscheidet der Controller noch, dass die Seite für das Auto angezeigt werden soll, das ist der View.
Würde die Seite jetzt ausgeliefert werden, wäre leider nichts sichtbar, da der View ja nach wie vor nichts vom Model weiß. Auch dies erledigt der Controller. Verinfacht gesagt teilt er dem View mit “Benutzer bitte dieses Auto-Objekt zum Anzeigen”.
Dadurch, dass der View nun das Auto-Objekt kennt, kann er über die Getter-Methoden des Models auf die Daten zugreifen.
Einige Grundsätze fehlen bei dieser recht einfachen Beschreibung des MVC-Pattern:
- Der View manipuliert keine Daten des Models
- Das Model ist das ahnungsloseste der drei Ebenen und darf nicht mit sicht auf den View oder den Controller entwickelt werden
- Der Controller füllt in den meisten Fällen nicht die Daten des Models, sondern veranlasst das Laden aus der Datenbank (Stichwort Data-Access-Objects)