Model-View-Controller-Service-Paradigma: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) |
Kowa (Diskussion | Beiträge) |
||
| Zeile 2: | Zeile 2: | ||
Das [[Model-View-Controller-Services-Paradigma|Model-View-Controller-Services]]-[[Paradigma]] oder -[[Pattern]], kurz MVCS, ist eine Erweiterung des [[Model-View-Controller-Paradigma]]s (MVC). Es bezeichnet ein [[Architekturmuster]] zur Trennung eines Programms in vier separate Einheiten: | Das [[Model-View-Controller-Services-Paradigma|Model-View-Controller-Services]]-[[Paradigma]] oder -[[Pattern]], kurz MVCS, ist eine Erweiterung des [[Model-View-Controller-Paradigma]]s (MVC). Es bezeichnet ein [[Architekturmuster]] zur Trennung eines Programms in vier separate Einheiten: | ||
[[Model (MVC)|Model]] (Modell), [[View (MVC)|View]] (Darstellung), [[Controller (MVC)|Controller]] (Steuerung) und | [[Model (MVC)|Model]] (Modell), [[View (MVC)|View]] (Illustration, Präsentation, Darstellung), [[Controller (MVC)|Controller]] (Steuerung) und | ||
[[Service (MVCS)|Service]] (Zugriff auf externe Daten). | [[Service (MVCS)|Service]] (Service, Zugriff auf externe Daten). | ||
= Der MVC-Prozess = | = Der MVC-Prozess = | ||
Version vom 28. September 2010, 14:36 Uhr
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 eines Programms in vier separate Einheiten: Model (Modell), View (Illustration, Präsentation, Darstellung), Controller (Steuerung) und Service (Service, Zugriff auf externe Daten).
Der MVC-Prozess
Das MVCS-Paradigma basiert auf folgender Grundüberlegung: Der aktuelle Zustand der Anwendungsdomäne wird im so genannten Model nachgebildet. Dem Benutzer (User) wird der aktuelle Zustand des Models mit Hilfe beliebig vieler Views präsentiert. Über einen Controller kann der Benutzer das Model manipulieren, das heißt, dessen Zustand (und damit auch die zugehörigen Views) ändern. Er kann auch veranlassen, dass die Daten des Models in einer externen Datenbank, Anwendung, XML-Datei o.Ä. dauerhaft gespeichert oder von dort in das Model eingelesen werden. Es ist sogar möglich, dass sich das Model selbstständig mit einem externen Datenpool synchronisiert.
gerahmt|links|rechts|Der MVCS-Prozess
Dieser so genannte MVCs-Prozess wird in der vorangehenden Abbildung visualisiert.
Beispiel Warenkorb
In einer Warenkorb-Anwendung werden im Model Daten über den Warenkorb und den Benutzer (sobald dieser eingeloggt ist) gespeichert: eine aktuelle Auswahl des Warenkataloges, die Waren, die im Korb enthalten sind, der Gesamtpreis und die Versandkosten der aktuellen Bestellung etc. Der Gesamtwarenbestand wird hingegen nicht im Model, sondern in einer externen Datenbank abgelegt.
Die View visualisiert Elemente der aktuellen Auswahl des Warenkataloges (siehe Model) 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 die View eine entsprechende Nachricht an den Controller weiter.
Der Controller analysiert die gewünschte Aktion des Benutzers und führt die entsprechenden Änderungen am Model durch. Zum Beispiel kann er veranlassen, die die aktuellen Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geändert, indem er die entsprechende Service-Kompenente veranlässt, die neuen Daten aus der Datenbank in das Model zu übertragen. Wenn der Benutzer zu guter Letzt eine Bestellung tätigt, veranlassst der Controller, dass die Bestellung aus dem Model mit Hilfe eines Services in die Datenbank übertragen wird.
Verfeinerung des MVC-Prozesses
Der zuvor definierte Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus zwei (oder noch mehr) Teilen: den eigentlichen Kern-Anwendungen(Domains) und einer Rahmen-Anwendung (Frame), die den Zugang zu den Kern-Anwendungen steuert. In diesem Fall gibt es mehrere relativ unabhängige MVCS-Prozesse: Die Frame-Komponenten dürfen auf zugehörigen Domain-Komponenten zugreifen. Der umgekehrte Weg sollte vermieden werden, damit die Domains problemlos in andere Umgebungen integriert werden können.
gerahmt|links|MVCS-Prozess 2 (mit Trennung in Frame und Domain)
Eine typische Aufgabe eines Frame-Services ist es, XML-Dateien zum Initialisieren des Systems einzulesen. Die Domain-Services greifen dagegen häufig auf Datenbanken oder Web-Anwendungen zu, die bestimmte Daten des Domain-Models 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 Kern-Anwendungen schreiben. Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung. Die Rahmen-Anwendung verknüpft die beiden Anwendungen.
Die Rahmen-Anwendung liest beispielsweise bei Spielende die erreichten Punkte aus dem Spiel-Model aus und leitet dies an das Highscore-Model weiter. Eine weitere Möglichkeit wäre, dass die Rahmen-Anwendung ü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.
