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

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Zeile 37: Zeile 37:
* Verarbeitung von Systemsignalen, wie z.B. einer Systemuhr (z.B. „Spielzeit ist abgelaufen“)
* Verarbeitung von Systemsignalen, wie z.B. einer Systemuhr (z.B. „Spielzeit ist abgelaufen“)
* Umsetzung der Komponentenlogik
* Umsetzung der Komponentenlogik
==Service==
Ein [[Model-View-Controller-Service-Paradigma/Service|Service]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/service|service]])
dient zur Kommunikation
mit der Außenwelt, d.h. mit Dienste-Anbietern wie [[Web-Server]]n, [[Datenbanksystem]]en oder auch [[Dateisystem]]en.
Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus [[Model-View-Controller-Service-Paradigma/Model|Modell]]en
bzw. [[Logic-Data-View-Controller-Service/Data|Datenmodulen]] auslesen und in ein externes
[[Repository]] schreiben, als auch Daten aus einem externen Repository lesen und in in ein Modell bzw. Datenmodul einfügen.


=Anmerkungen=
=Anmerkungen=

Version vom 15. Juli 2011, 12:53 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

gerahmt||rechts|MVCS-Module Das Model-View-Controller-Services-Paradigma, MVCS-Paradigma oder 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).

Model (Modell)

Ein MVCS-Modell (engl. MVC model) einer MVC-Anwendung dient zur Speicherung bestimmter Daten, d.h. zur Speicherung von Teilen des aktuellen Zustands der Anwendung.

Ein MVCS-Modell kann weitere Aufgaben übernehmen:

  • anderen Modulen Zugriff auf die Zustandsdaten gewähren
  • andere Module über Änderungen informieren (meist mittels des Observer-Patterns)
  • Umsetzung der Komponentenlogik

View (Darstellung, Präsentation)

MVCS-Views (engl. MVCS views) sind die grafischen, akustischen, haptischen und olfaktorischen Schittstellen einer MVCS-Anwendung. Sie „visualisieren“ Daten, die in Modellen der Anwendung enthalten sind.

Eine MVCS-View kann weitere Aufgaben übernehmen:

  • bei Daten-Änderungen in den zugehörigen Modellen der Anwendung die View-Repräsentation dieser Daten automatisch anpassen
  • Benutzeraktionen, die über grafische Eingabeelemente – wie Textfelder oder Buttons – erfolgen, an einen Controller weiterleiten
  • Controller-Informationen (wie z.B. Fehler-Meldungen oder Service-Status-Meldungen) visualisieren

Controller (Steuerung)

MVCS-Controller (engl. MVCS controllers) dienen zur Steuerung einer MVCS-Anwendung. Dazu nimmt ein Controller Eingaben aus verschiedensten Quellen entgegen (z.B. Sensor-Daten oder Daten, die ein Benutzer über eine beliebige Benutzer-Schnittstelle wie eine Tastatur oder eine Maus eingibt) und leitet diese bereinigt und normalisiert an ein Modell weiter.

Ein MVCS-Controller kann weitere Aufgaben übernehmen:

  • Verarbeitung von Systemsignalen, wie z.B. einer Systemuhr (z.B. „Spielzeit ist abgelaufen“)
  • Umsetzung der Komponentenlogik

Service

Ein Service (engl. service) dient zur Kommunikation mit der Außenwelt, d.h. mit Dienste-Anbietern wie Web-Servern, Datenbanksystemen oder auch Dateisystemen. Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus Modellen bzw. Datenmodulen auslesen und in ein externes Repository schreiben, als auch Daten aus einem externen Repository lesen und in in ein Modell bzw. Datenmodul einfügen.

Anmerkungen

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.