Model-View-Controller-Service-Paradigma
Definition
Das Model-View-Controller-Services-Paradigma oder -Pattern, kurz MVCS, ist eine Erweiterung des Model-View-Controller-Paradigmas (MVC). Es bezeichnet ein Architekturmuster zur Trennung einer Anwendungs-Komponente in vier separate Einheiten (Module): Model (Modell), View (Illustration, Präsentation, Darstellung), Controller (Steuerung) und Service (Service, Zugriff auf externe Daten).
Der MVCS-Prozess
gerahmt|links|rechts|Der MVCS-Prozess Das MVCS-Paradigma erweitert das MVC-Paradigma um die so genannte Servicekomponenten. Die Aufgabe der Präsentationskomponente (View) ändert sich nicht. Die Servicemodule übernehmen die Aufgabe, mit externen Anwendungen/Datenpools zu kommunizieren. Hierbei handelt es sich um eine Aufgabe, von der nicht klar ist, ob sie im MVC-Paradigma eher von den Modellkomponenten oder den Steuerungskomponenten übernommen werden sollte. Externe Datenbestände gehören eigentlich zu Modell. Die Steuerung des Transports dieser Daten wäre allerdings eher eine Aufgabe der Steuerkomponenten. Joe Berkovitz schlägt daher vor, für diese Aufgabe eine eigenstädige Komponente zu etablieren.
Über eine Steuerkomponente kann der Benutzer das Modell manipulieren, das heißt, dessen Zustand (und damit auch die zugehörigen Views) ändern. Er kann insbesondere veranlassen, dass die Daten des Modells an eine externe Anwendung weitergeleitet oder in einer externen Datenbank, XML-Datei o.Ä. dauerhaft gespeichert werden. Auch das Lesen von Daten aus einer externen Datenquelle kann auf diese Weise initiiert werden.
Es ist sogar möglich, das Modell mit Hilfe einer Servicekomponenten automatisch mit einem externen Datenpool zu synchronisieren. Hierbei kommt keine Steuerkomponente zum Einsatz.
Beispiel Warenkorb
In einer Warenkorb-Anwendung werden im Modell Daten über den Warenkorb und den Benutzer (sobald dieser eingeloggt ist) gespeichert: eine aktuelle Auswahl des Warenkataloges, den Inhalt des Warenkorbs, der Gesamtpreis und die Versandkosten der Waren im Warenkorb etc. Der Warenkatalog selbst wird hingegen nicht im Modell, sondern in einer externen Datenbank abgelegt.
Die View visualisiert Elemente der aktuellen Auswahl des Warenkataloges (siehe Modell) mit Hilfe von Texten, Bildern und Videos. Der Benutzer kann die Auswahl der visualierten Elemente durch Filter oder Navigation abändern, er kann Elemente des Kataloges in seinen Warenkorb legen und dort wieder entfernen etc. Für all diese Aktionen werden dem Benutzer in der View spezielle Eingabefelder ([Checkbox]]es, Drop-Down-Menüs, Textfelder, Links etc.) präsentiert. Jedes mal, wenn der Benutzer eine dieser Felder mit Hilfe der Maus oder der Tastatur bedient, leitet das Darstellungsmodul eine entsprechende Nachricht an das zuständige Steuermodul weiter.
Das Steuermodul analysiert die gewünschte Aktion des Benutzers und führt die entsprechenden Änderungen am Modell durch. Zum Beispiel kann sie veranlassen, die aktuelle Auswahl des Warenkataloges den Wünschen des Benutzers gemäß zu ändern, indem sie die entsprechende Service-Kompenente veranlässt, die neuen Daten aus der Datenbank in das Modell zu übertragen.
Wenn der Benutzer zu guter Letzt eine Bestellung tätigt, veranlassst die Steuerkomponente, dass die Bestellung aus dem Modell mit Hilfe eines Services an eine geeignete Anwendung weitergeleitet wird.
Verfeinerung des MVCS-Prozesses
Genauso wie der MVC-Prozess kann auch der MVCS-Prozess verfeinert werden. Auch hier bietet sich die Aufteilung in Kernkomponenten (Domain-Komponenten) und eine Rahmenkomponente (Frame-Komponente) an, die den Zugang zu und zwischen den Kernkomponenten steuert. In diesem Fall gibt es mehrere relativ unabhängige MVCS-Prozesse: Die äußeren Komponenten (wie z.B. eine Rahmenkomponente) darf auf innere Komponenten (wie z.B. eine Kernkomponente) zugreifen. Der umgekehrte Weg sollte allerdings vermieden werden, damit die Kernkomponenten problemlos in andere Umgebungen integriert werden können.
gerahmt|links|MVCS-Prozess 2 (mit Trennung in äußere und innere Komponenten)
Eine typische Aufgabe eines Rahmenservices ist es, XML-Dateien zum Initialisieren des Systems einzulesen. Die Kernservice greifen dagegen häufig auf Datenbanken oder Web-Anwendungen zu, die bestimmte Daten des Kernmodells dauerhaft speichern (vgl. obiges Beispiel).
Beispiel „Spiel mit Highscore-Verwaltung“
Wenn man ein „Spiel mit Highscore-Verwaltung“ realisieren möchte, sollte man zwei unanhängige Kernanwendungen schreiben. Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung. Die Rahmenanwendung verknüpft diese beiden Anwendungen.
Die Rahmenanwendung liest beispielsweise bei Spielende die erreichten Punkte aus dem Spielmodell aus und leitet diese an das Highscore-Modell weiter. Eine weitere Möglichkeit wäre, dass die Rahmenanwendung über die Highscore-Anwendung ermittelt, ob der Spieler schon mindestens fünf Level erfolgreich gespielt hat. Nur in diesem Fall gewährt sie den Zugang zum Trainingsmodus des Spiels.
Quellen
- Berkovitz, Joe (2006): An architectural blueprint for Flex applications
- Kowarschick, W.: Multimedia-Programmierung
