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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 76: Zeile 76:
=Siehe auch=
=Siehe auch=
*[[Model-View-Controller-Paradigma]]
*[[Model-View-Controller-Paradigma]]
*[[View-Controller-Logic-Service-Data-Paradigma]]<noinclude>[[Kategorie:Objektorientierte Programmierung]]
*[[Logic-Data-View-Controller-Service-Paradigma]]<noinclude>[[Kategorie:Objektorientierte Programmierung]]
[[Kategorie:Glossar]][[Kategorie:MVC]]
[[Kategorie:Glossar]][[Kategorie:MVC]]
[[en:MVCS]]
[[en:MVCS]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]
{{{{SITENAME}}-konformer Artikel}}</noinclude>
{{{{SITENAME}}-konformer Artikel}}</noinclude>

Version vom 13. Mai 2011, 12:34 Uhr

Dieser Artikel erfüllt die GlossarWiki-Qualitätsanforderungen nur teilweise:

Korrektheit: 4
(großteils überprüft)
Umfang: 3
(einige wichtige Fakten fehlen)
Quellenangaben: 4
(fast vollständig vorhanden)
Quellenarten: 4
(sehr gut)
Konformität: 4
(sehr gut)

Diese Bewertungen beziehen sich auf alle im nachfolgenden Menü genannten Artikel gleichermaßen.

Definition

Das Model-View-Controller-Services-Paradigma oder -Pattern, kurz MVCS, ist eine Erweiterung des Model-View-Controller-Paradigmas (MVC). Es bezeichnet ein Architekturmuster, bei der eine Anwendungs-Komponente in vier eigenständige Module unterteilt wird: Model (Modell), View (Darstellung, Präsentation), Controller (Steuerung) und Service (Service, Zugriff auf externe Daten).


MVCS-Paradigma

Man sagt, dass eine Anwendung oder ein Programmsystem auf dem MVCS-Paradigma beruht, wenn das Prinzip der Aufteilung zentraler Komponenten in die vier Module Model, View, Controller und Service wesentlicher Bestandteil dieser Anwendung bzw. dieses Systems ist.


MVCS-Pattern

Wenn darüber hinaus eine konkrete Struktur für die vier Module Model, View, Controller und Service vorgegeben ist (z.B. in Form von Klassen-Templates), spricht man vom MVCS-Pattern.

Der MVCS-Prozess

gerahmt|rechts|Der MVCS-Prozess Das MVCS-Paradigma erweitert das MVC-Paradigma um die so genannte Servicemodule. 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 Modellmodulen oder den Steuerungsmodulen übernommen werden sollte. Externe Datenbestände gehören eigentlich zu Modell. Die Steuerung des Transports dieser Daten wäre allerdings eher eine Aufgabe der Steuermodule. Joe Berkovitz schlägt daher vor, für diese Aufgabe eigenständige Module zu etablieren.

Über ein Steuermodul 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 – mit Hilfe eines Servicemoduls – 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 Besteller (sobald dieser eingeloggt ist) gespeichert: eine aktuelle Auswahl des Warenkataloges, den Inhalt des Warenkorbs, der Gesamtpreis der Waren im Warenkorb, der Adresse des Besterller 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 das entsprechende Servicemodul veranlässt, die neuen Daten aus der Datenbank in das Modell zu übertragen.

Wenn der Benutzer zu guter Letzt eine Bestellung tätigt, veranlassst das Steuermodul, dass die Bestellung aus dem Modell mit Hilfe eines Services an eine geeignete Anwendung weitergeleitet wird.

Kommunikation zwischen zwei MVCS-Komponenten

Genauso wie mehrere MVC-Komponenten miteinander kommunizieren können, können auch mehrere MVCS-Komponenten miteinander kommunizieren.

Viele Anwendungen bestehen aus mehreren MVCS-Komponenten: Eine oder mehrere Kernanwendungen (Domain-Komponenten) sowie einer Rahmenanwendung (Frame-Komponente), die den Zugang zu und zwischen den Kernanwendungen steuert. In diesem Fall gibt es mehrere relativ unabhängige MVC-Prozesse. Die äußeren Komponenten (wie z.B. die Rahmenkomponente) können dabei mit den inneren Komponenten (wie z.B. die Kernkomponenten) kommunizieren. Der umgekehrte Weg sollte vermieden werden, damit Kernkomponenten problemlos in andere Umgebungen integriert werden können. gerahmt|links|MVCS-Prozess 2 (mit Trennung in äußere und innere MVCS-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

Siehe auch


Dieser Artikel ist GlossarWiki-konform.