Da es eine Menge an Design Patterns gibt - die das Leben eines Entwicklers bereichern - stellt sich doch die Frage: „Womit beginnt man am Besten?“
Nun ja … nach einigen Überlegungen habe ich mich für das Nächstliegendste entschieden und beginne mit dem abstraktesten und gleichzeitig umstrittensten Pattern, dem Model View Controller Pattern. Umstritten deshalb weil man sich uneins ist, ob das MVC-Pattern eher ein Architektur- oder ein Design-Pattern ist! Aber für mich ist es ehrlich gesagt einfach nur ein abstraktes Pattern, das sowohl für die Gestaltung einzelner Applikationsschichten als auch für die Planung der Architektur eingesetzt werden kann. Und bei späteren Beispielen anderer, speziellerer Patterns wird sich zeigen, dass diese auf dem MVC Gedanken aufsetzen.
Genug des Vorgeplänkels und ab an die harten Fakten:
Warum existiert dieses Pattern?
Die Daseinsberechtigung vieler Computersysteme bzw. vieler Softwarelösungen besteht im wesentlichen darin, dass zum Einen Daten aus einem Datenspeicher geholt und dem User auf irgendeine Art angezeigt werden, zum Anderen die vom User veränderten Daten wieder in den Datenspeicher zurück fließen. Etwas komplexere Systeme bereiten - in einem Zwischenschritt - die Daten ggf. noch auf, aber im wesentlichen geht es bei den angesprochenen „Systemen“ um den Informationsfluss zwischen UI und Datenspeicher. Diese Tatsache führt oftmals dazu, dass diese beiden Bereiche so eng wie möglich aneinander gebunden werden um erhoffte Performance Vorteile und verringerten Entwicklungsaufwand zu erreichen. Am Ende entsteht ein sogenanntes monolitisches Gebilde, was einige Probleme aufwirft:
- fehlende Flexibilität
- geringe (Teil-)Wiederverwendbarkeit
- schlechte bis fehlende Struktur
Grundlagen/Grundgedanke dieses Patterns
Das Model-View-Controller Pattern im klassischen Sinne setzt auf die in der folgenden Abbildung gezeigten drei Komponenten auf, die je nach Implementierung unterschiedlich stark voneinander abhängen.
.gif)
Entsprechend lassen sich auch die Aufgaben der einzelnen Komponenten recht abstrakt formulieren:
Model - Die Datengrundlage für die - wie auch immer geartete - Umsetzung des MVC Patterns, findet sich im Model wieder. Diese Komponente könnte man ohne weiteres als den unabhängigsten Part der Drei bezeichnen, da es keinerlei Kenntniss von Schnittstellen den anderen Komponenten besitzt, so geschieht die Bekanntgabe von Änderungen der Datengrundlage hier auch nach dem Observer-Pattern. Das Model führt Manipulationen der Daten auf Anfrage durch.
View - Erst einmal findet hier die Präsentation der relevanten Daten aus dem Model statt, über deren Änderungen sie mittels Anwendung des Observer Patterns informiert wird. Jede View besitzt damit quasi ihr eigenes Model. Weiterhin besitzt die View auch Kenntniss der Schnittstellen Ihrer zugehörigen Controller, da Sie für die Entgegennahme und Weitergabe von Benutzerinteraktionen an Diese verantwortlich ist. Eine Verarbeitung von durch Benutzer übergebenen Daten findet in der View nicht statt. Views Verwenden das Composite-Pattern.
Controller - Als Herzstück der MVC Komponenten verwaltet der Controller 1-n Views. Dazu gehört u.a. das Entgegennehmen und Verarbeiten der eintreffenden Benutzerinteraktionen und die daraus möglicherweise resultierenden Änderungen am Model der View anzustoßen. Außerdem besitzt die Steuerung Mechanismen um die Interaktionsmöglichkeiten der zugehörigen Views einzuschränken.
Anmerkung: Controller und View werden nach dem Strategy Pattern verwendet, wobei der Controller die Strategy (den Algorithmus) bildet.
Das ist die theoretische Grundlage auf der die diversen Implementierungen dieses Patterns mehr oder weniger genau aufsetzen. Gerade im Kontext der Design Pattern gibt es eine Vielzahl von Implementierungsansätzen rund um MVC die sich Eigenheiten von Programmiersprachen zu eigen machen oder einfach durch ihr Einsatzfeld als GUI Framework oder Web-basiertes Frameworks unterschiedliche Lösungsansätze verfolgen. Der Problemlösungsansatz des MVC Pattern wird dabei jedoch von all diesen Varianten verfolgt.
Einige konkrete Beispiele zu Implementierungen rund um das MVC Pattern und weitere Infos folgen im 2. Teil ... to be continued
