Model-View-Controller-Service-Paradigma: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Zeile 7: Zeile 7:
= Der MVCS-Prozess =
= Der MVCS-Prozess =
[[Medium:MVCS-Prozess 01.png|gerahmt|links|rechts|Der MVCS-Prozess]]
[[Medium:MVCS-Prozess 01.png|gerahmt|links|rechts|Der MVCS-Prozess]]
Das MVCS-Paradigma basiert auf folgender Grundüberlegung: Der aktuelle Zustand der [[Anwendungsdomäne]] wird im so genannten Modell nachgebildet. Dem Benutzer (User) wird der aktuelle Zustand des Modells mit Hilfe beliebig vieler Views präsentiert. Über eine Steuerkomponente kann der Benutzer das Modell 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. Hierzu bedient sich die Steurkomponete einer geeigneten Servicekomponente. Es ist sogar möglich, dass das Modell mit Hilfe einer Servicekomponenten automatisch mit einem externen Datenpool synchronisiert wird.  
Das MVCS-Paradigma erweitert das [[MVC-Paradigma]] um die sogenannte Servicekomponenten. Die Aufgabe der Präsentationskomponente (View) ändert sich nicht. Die Servicekomponeten ü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 Steurkomponenten. 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 Steurkomponente zum Einsatz.


== Beispiel Warenkorb==
== Beispiel Warenkorb==
Zeile 20: Zeile 24:
dem Benutzer in der View spezielle Eingabefelder ([Checkbox]]es, [[Drop-Down-Menü]]s, [[Textfeld]]er, [[Link]]s etc.) präsentiert.
dem Benutzer in der View spezielle Eingabefelder ([Checkbox]]es, [[Drop-Down-Menü]]s, [[Textfeld]]er, [[Link]]s etc.) präsentiert.
Jedes mal, wenn der Benutzer eine dieser Felder mit Hilfe der Maus oder der Tastatur bedient, leitet die  
Jedes mal, wenn der Benutzer eine dieser Felder mit Hilfe der Maus oder der Tastatur bedient, leitet die  
Darstellungskomponete eine entsprechende Nachricht an die zustänsige Steurkomponete weiter.
Darstellungskomponete eine entsprechende Nachricht an die zuständige Steurkomponete weiter.


Die Steurkomponete analysiert die gewünschte Aktion des Benutzers und führt die entsprechenden Änderungen am Modell durch.
Die Steurkomponete analysiert die gewünschte Aktion des Benutzers und führt die entsprechenden Änderungen am Modell durch.
Zeile 26: Zeile 30:
indem sie die entsprechende Service-Kompenente veranlässt, die neuen Daten aus der Datenbank in das Modell zu übertragen.
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 Steurkomponente, dass die Bestellung aus dem Modell mit Hilfe eines Services in die Datenbank übertragen wird.
Wenn der Benutzer zu guter Letzt eine Bestellung tätigt, veranlassst die Steurkomponente,  
dass die Bestellung aus dem Modell mit Hilfe eines Services an eine geeignete Anwendung weitergeleitet wird.


= Verfeinerung des MVC-Prozesses=
= Verfeinerung des MVC-Prozesses=

Version vom 28. September 2010, 17:43 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 MVCS-Prozess

gerahmt|links|rechts|Der MVCS-Prozess Das MVCS-Paradigma erweitert das MVC-Paradigma um die sogenannte Servicekomponenten. Die Aufgabe der Präsentationskomponente (View) ändert sich nicht. Die Servicekomponeten ü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 Steurkomponenten. 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 Steurkomponente 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 die Darstellungskomponete eine entsprechende Nachricht an die zuständige Steurkomponete weiter.

Die Steurkomponete 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 Steurkomponente, dass die Bestellung aus dem Modell mit Hilfe eines Services an eine geeignete Anwendung weitergeleitet 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.

Quellen