Logic-Data-View-Controller-Service-Paradigma: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
=Definition=
=Definition=
Das [[Data-Service-Logic-Controller-View-Pattern]] oder [[Data-Service-Logic-Controller-View-Pattern|-Paradigma]], kurz [[DSLCV]],  bezeichnet ein [[Architekturmuster]] zur Trennung einer [[Komponente (UML)|Anwendungs-Komponente]] in fünf separate Einheiten (Module):  
Das [[View-Controller-Logic-Service-Data-Pattern]] oder [[View-Controller-Logic-Service-Data-Pattern|-Paradigma]], kurz [[VCLSD]],  bezeichnet ein [[Architekturmuster]] zur Trennung einer [[Komponente (UML)|Anwendungs-Komponente]] in fünf separate Einheiten (Module):  
[[Data (DSLCV)|Data]] (Daten),  [[Service (MVCS)|Service]] (Service), [[Logic (DSLCV)|Logic]] (Logik), , [[Controller (MVC)|Controller]] (Steuerung) und [[View (MVC)|View]] (Darstellung).
[[Data (VCLSD)|Data]] (Daten),  [[Service (MVCS)|Service]] (Service), [[Logic (VCLSD)|Logic]] (Logik), [[Controller (MVC)|Controller]] (Steuerung) und [[View (MVC)|View]] (Darstellung).


=Das DSLCV-Pattern als spezielles Layer-Pattern=
=Das VCLSD-Pattern als spezielles Layer-Pattern=
[[Medium:DSLCV Layer Pattern 01.png|gerahmt||rechts|Das DSLCV-Pattern als Spezialfall des [[Layer-Pattern]]s]]
[[Medium:VCLSD Layer Pattern 01.png|gerahmt||rechts|Das VCLSD-Pattern als Spezialfall des [[Layer-Pattern]]s]]


Dieses Pattern ist eine Verfeinerung des [[Model-View-Controller-Services-Pattern]]s (MVCS-Pattern).  
Dieses Pattern ist eine Verfeinerung des [[Model-View-Controller-Services-Pattern]]s (MVCS-Pattern).  


Eine DLSVC-Komponente besteht im Gegensatz zum MVCS-Pattern nicht aus vier, sondern aus fünf Modulen.  
Eine VCLSD-Komponente besteht im Gegensatz zum MVCS-Pattern nicht aus vier, sondern aus fünf Modulen.  
Der Grund dafür ist, dass das Modell des MVCS-Patterns normalerweise zwei Aufgaben übernimmt: Die Speicherung der Anwendungsdaten und die Realisierung der Anwendungslogik.  
Der Grund dafür ist, dass das Modell des MVCS-Patterns normalerweise zwei Aufgaben übernimmt: Die Speicherung der Anwendungsdaten und die Realisierung der Anwendungslogik.  
(Manchmal übernimmt auch der Controller die Realisierung der Anwendungslogik.)
(Manchmal übernimmt auch der Controller die Realisierung der Anwendungslogik.)
Im DSLCV-Pattern wird ein Modellmodul daher in zwei Module aufgeteilt: ein Datenmodul (Data) und ein Logikmodul (Logic).
Im VCLSD-Pattern wird ein Modellmodul daher in zwei Module aufgeteilt: ein Datenmodul (Data) und ein Logikmodul (Logic).
Der Controller darf nun nicht mehr direkt schreibend auf ein Datenmodul zugreifen. Dies ist jetzt die Aufgabe der Logikmodule (und evtl. der Servicemodule).
Der Controller darf nun nicht mehr direkt schreibend auf ein Datenmodul zugreifen. Dies ist jetzt die Aufgabe der Logikmodule (und evtl. der Servicemodule).


Die fünf Module einer DSLCV-Komponente sind gemäß dem Layer-Pattern in Ebenen angeordnet. Die höheren Ebenen können auf tiefergelegene Ebenen zugreifen, aber nicht umgekehrt.
Die fünf Module einer VCLSD-Komponente sind gemäß dem Layer-Pattern in Ebenen angeordnet. Die höheren Ebenen können auf tiefergelegene Ebenen zugreifen, aber nicht umgekehrt.
Die unserste Ebene ist [[Data (DSLCV)|Data]]. Das zugehörige Modul weiß nichts von den über ihr liegenden Modulen und kann mit diesen nur mit
Die unserste Ebene ist [[Data (VCLSD)|Data]]. Das zugehörige Modul weiß nichts von den über ihr liegenden Modulen und kann mit diesen nur mit
Hilfe des [[Observer-Pattern]]s kommunizieren.
Hilfe des [[Observer-Pattern]]s kommunizieren.


Zeile 32: Zeile 32:


==Anmerkung==
==Anmerkung==
Man beachte, das der Name DSLVC-Pattern die Layer-Schichtung der zugehörigen Module wiederspiegelt. Entsprechend sollte man eigentlich vom MCV-Pattern
Man beachte, das der Name VCLSD-Pattern die Layer-Schichtung der zugehörigen Module wiederspiegelt. Entsprechend sollte man eigentlich vom MCV-Pattern
anstelle vom [[Model-View-Controller-Pattern|MVC-Pattern]] sprechen, da auch das MVC-Pattern ein spezielles Layer-Pattern ist.
anstelle vom [[Model-View-Controller-Pattern|MVC-Pattern]] sprechen, da auch das MVC-Pattern ein spezielles Layer-Pattern ist.


= Der DSLCV-Prozess =
= Der VCLSD-Prozess =
[[Medium:DSLCV-Prozess 01.png|gerahmt||rechts|DSLCV-Prozess]]
[[Medium:VCLSD-Prozess 01.png|gerahmt||rechts|Der VCLSD-Prozess]]


== Beispiel Jump 'n' Run==
== Beispiel Jump 'n' Run==
Zeile 63: Zeile 63:
=== Modularität ===
=== Modularität ===


Der große Vorteil des DSLCV-Patterns ist die Modularität. Das [[Programmierprinzipien|Prinzip]] „[[Separation of Concerns]]“
Der große Vorteil des VCLSD-Patterns ist die Modularität. Das [[Programmierprinzipien|Prinzip]] „[[Separation of Concerns]]“
wird hierbei bachtet: Jede Aufgabe wird von einer eigenen Komponente bearbeitet.
wird hierbei bachtet: Jede Aufgabe wird von einer eigenen Komponente bearbeitet.


Zeile 80: Zeile 80:
wenn ein Login-Vorgang erfolgreich abgschlossen wurde.
wenn ein Login-Vorgang erfolgreich abgschlossen wurde.


= Verfeinerung des DSLCV-Prozesses=
= Verfeinerung des VCLSD-Prozesses=
Genauso wie der [[Model-View-ControllerProzess|MVC-Prozess]] und der [[Model-View-Controller-Service-Prozess|MVCS-Prozess]] kann auch der DSLCV-Prozess verfeinert werden. Auch hier  
Genauso wie der [[Model-View-ControllerProzess|MVC-Prozess]] und der [[Model-View-Controller-Service-Prozess|MVCS-Prozess]] kann auch der VCLSD-Prozess verfeinert werden. Auch hier  
kann eine „äußere DSLCV-Komponente“ eine „innere DSLCV-Komponente“ verwenden:
kann eine „äußere VCLSD-Komponente“ eine „innere VCLSD-Komponente“ verwenden:
Die Module der äußeren Komponente dürfen auf die Module der inneren Komponente zugreifen.
Die Module der äußeren Komponente dürfen auf die Module der inneren Komponente zugreifen.
Der umgekehrte Weg sollte allerdings vermieden werden, damit die innere Komponente problemlos in andere Umgebungen integriert werden können.
Der umgekehrte Weg sollte allerdings vermieden werden, damit die innere Komponente problemlos in andere Umgebungen integriert werden können.


[[Medium:DSLCV-Prozess 02.png|gerahmt|links|DSLCV-Prozess 2 (mit Trennung in eine äußere und eine innere Komponente)]]
[[Medium:VCLSD-Prozess 02.png|gerahmt|links|Der VCLSD-Prozess mit Trennung in eine äußere und eine innere Komponente]]
 
 
==Beispiel „Spiel mit Highscore-Verwaltung“==
==Beispiel „Spiel mit Highscore-Verwaltung“==
Zeile 99: Zeile 99:
=Implementierung=
=Implementierung=


Das DSLCV-Pattern lässt sich auf mehrere Arten implementieren:
Das VCLSD-Pattern lässt sich auf mehrere Arten implementieren:
* [[Data-Service-Logic-Controller-View-Pattern/Implementierung: Dependency Injection|Initialsierung mittels Depenency Injection]]
* [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Dependency Injection|Initialsierung mittels Depenency Injection]]
* [[Data-Service-Logic-Controller-View-Pattern/Implementierung: Singleton|Initialsierung mittels Singletons]]
* [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Singleton|Initialsierung mittels Singletons]]
* [[Data-Service-Logic-Controller-View-Pattern/Implementierung: Observer|Kommunikation ausschließlich mittels des Observer Patterns]]
* [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Observer|Kommunikation ausschließlich mittels des Observer Patterns]]
<noinclude>
<noinclude>
=Quellen=
=Quellen=
Zeile 112: Zeile 112:
<noinclude>[[Kategorie:Objektorientierte Programmierung]]
<noinclude>[[Kategorie:Objektorientierte Programmierung]]
[[Kategorie:Glossar]][[Kategorie:MVC]]
[[Kategorie:Glossar]][[Kategorie:MVC]]
[[en:DSLCV]]
[[en:VCLSD]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]
[[Kategorie:Kapitel:Multimedia-Programmierung]]
{{{{SITENAME}}-konformer Artikel}}</noinclude>
{{{{SITENAME}}-konformer Artikel}}</noinclude>

Version vom 4. April 2011, 17:03 Uhr

Definition

Das View-Controller-Logic-Service-Data-Pattern oder -Paradigma, kurz VCLSD, bezeichnet ein Architekturmuster zur Trennung einer Anwendungs-Komponente in fünf separate Einheiten (Module): Data (Daten), Service (Service), Logic (Logik), Controller (Steuerung) und View (Darstellung).

Das VCLSD-Pattern als spezielles Layer-Pattern

[[Medium:VCLSD Layer Pattern 01.png|gerahmt||rechts|Das VCLSD-Pattern als Spezialfall des Layer-Patterns]]

Dieses Pattern ist eine Verfeinerung des Model-View-Controller-Services-Patterns (MVCS-Pattern).

Eine VCLSD-Komponente besteht im Gegensatz zum MVCS-Pattern nicht aus vier, sondern aus fünf Modulen. Der Grund dafür ist, dass das Modell des MVCS-Patterns normalerweise zwei Aufgaben übernimmt: Die Speicherung der Anwendungsdaten und die Realisierung der Anwendungslogik. (Manchmal übernimmt auch der Controller die Realisierung der Anwendungslogik.) Im VCLSD-Pattern wird ein Modellmodul daher in zwei Module aufgeteilt: ein Datenmodul (Data) und ein Logikmodul (Logic). Der Controller darf nun nicht mehr direkt schreibend auf ein Datenmodul zugreifen. Dies ist jetzt die Aufgabe der Logikmodule (und evtl. der Servicemodule).

Die fünf Module einer VCLSD-Komponente sind gemäß dem Layer-Pattern in Ebenen angeordnet. Die höheren Ebenen können auf tiefergelegene Ebenen zugreifen, aber nicht umgekehrt. Die unserste Ebene ist Data. Das zugehörige Modul weiß nichts von den über ihr liegenden Modulen und kann mit diesen nur mit Hilfe des Observer-Patterns kommunizieren.

Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese (sowie eventuell auf externe Datenquellen) zugreifen.

Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel um zu überprüfen, ob die entsprechenden Zugriffsrechte für eine Datenmanipulation überhaut gegeben sind).

Ein Controllermodul kann nur auf Logikmodule zugreifen, um Benutzeraktionen an dieses (bereinigt und normalisiert) weiterzuleiten.

Eine View kommuniziert i. Allg. direkt nur mit Controllermodulen um dieser Benutzeraktionen, die über die View erfolgen, mitzuteilen. Ein direkter Zugriff auf ein Datenmodul ist nur dann notwendig, wenn die Nachrichten, die von den Datenmodulen verschickt werden, nicht alle relevanten Informationen enthalten.

Der Benutzer stellt schließlich das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controllermodulen.

Anmerkung

Man beachte, das der Name VCLSD-Pattern die Layer-Schichtung der zugehörigen Module wiederspiegelt. Entsprechend sollte man eigentlich vom MCV-Pattern anstelle vom MVC-Pattern sprechen, da auch das MVC-Pattern ein spezielles Layer-Pattern ist.

Der VCLSD-Prozess

gerahmt||rechts|Der VCLSD-Prozess

Beispiel Jump 'n' Run

In einem Jump-'n'-Run-Spiel werden Daten (Data) über die Spielfigur (Position, Laufrichtung, Geschwindigkeit ...), die Gegner, die Gegenstände etc. gespeichert.

Die View' visualisiert die Elemente des Spiels mit Hilfe von Bildern und Animationen (Walk cyles etc.). Jede Änderung an den Daten hat, sofern sie sich im für den Spieler sichtbaren Bereich befindet, eine Anpassung der View zur Folge.

Der Spieler steuert die Spielfigur mit Hilfe der Tastatur. Jeder Tastendruck wird vom Controller analysiert und zur Manipulation der Spielfigur an die Logik-Komponente (Logic) weitergeleitet.

Man beachte, dass die Logik-Komponente i. Allg. aktiv sein kann: Sie kann die Daten selbstständig, d.h. auch ohne Manipultation durch den Controller verändern. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, direkt von der Logik-Komponente gesteuert.

Mit Hilfe einer Service-Komponente (Service) kann das Spiel zu einem Multiuser-Spiel erweitert werden. Die Service-Komponente hat dann zwei Aufgaben:

  1. Die Position des Avatars (d.h. der eigenen Spielfigur) an einen zentralen Server zu übertragen.
  2. Die Postition anderer Spielfiguren und möglicher Gegner vom zentralen Server zu holen und in die eigene Datenkomponente zu schreiben.

Eine weitere typische Aufgabe der Service-Komponente ist es, die Daten-Komponente bei Programmstart zu initialisieren. Zu diesem Zweck sollten die Service-Komponente eine Initialisierungsmethode implementieren, die vom Hauptprogramm direkt aufgerufen wird, nachdem die Daten- und die Service-Komponete erzeugt wurden.

Modularität

Der große Vorteil des VCLSD-Patterns ist die Modularität. Das PrinzipSeparation of Concerns“ wird hierbei bachtet: Jede Aufgabe wird von einer eigenen Komponente bearbeitet.

Beispielsweise kann ein Jump'n'Run-Spiel, das derartig modular aufgebaut ist, sehr leicht an neue Gegebenheiten angepasst werden. Jede der folgenden Änderungen hat lediglich Auswirkungen auf eine der fünf Module:

  1. Änderung der Darstellung (d.h. der View): Die View kann jederzeit durch neue Skins aktualisiert werden. Es ist auch möglich, die 2D-Ansicht des Spiels durch eine Pseudo-3D-Ansicht zu ersetzen. Bei einem Multiuser-Spiel hat sowieso jeder Spieler seine eigene Sicht auf die Szenerie.
  2. Änderung der Spielsteuerung (d.h. des Controllers): Anstelle einer Steuerung der Spielfigur durch die Tastatur kann beispielsweise eine Steuerung der Spielfigur durch eine WiiMote erfolgen. Hier wäre es auch denkbar, dass der WiiMote-Controller bestimmte Datenänderungen (wie z.B. Kollisionen) per Force Feedback an den Benutzer zurückmeldet. Dazu muss sich der Controller ebenfalls über Datenänderungen informieren lassen.
  3. Änderung der Spiellogik (d.h. der Logikkomponente): Die KI-Engine zur Steuerung der Gegener kann beispielsweise durch eine bessere Engine ersetzt werden.
  4. Änderung der Dateninitialisierung (d.h. der Service-Komponente): Wenn die Dateninitialisierung künfig beispielsweise nicht mehr über XML, sondern über SQL erfolgen soll, muss ledichlich die entsprechende Service-Komponente ausgetauscht werden.
  5. Änderung des Spielservers (d.h. der Service-Komponente): Es ist jederzeit möglich, ein Multi-User-Spiel über einen anderen Server (mit einer anderen Architektur) laufen zu lassen.

Auch die Datenkomponente kann ausgetauscht werden, wenn z.B. andere Datenstrukturen zur Speicherung der Daten eingesetzt werden sollen. Es ist darüber hinaus möglich, einer Datenkomponente Filter vorzuschalten (vgl. Aspektorientierte Programmierung). Zum Beispiel kann auf diese Weise ine Login-Mechanismus realisiert werden: Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich abgschlossen wurde.

Verfeinerung des VCLSD-Prozesses

Genauso wie der MVC-Prozess und der MVCS-Prozess kann auch der VCLSD-Prozess verfeinert werden. Auch hier kann eine „äußere VCLSD-Komponente“ eine „innere VCLSD-Komponente“ verwenden: Die Module der äußeren Komponente dürfen auf die Module der inneren Komponente zugreifen. Der umgekehrte Weg sollte allerdings vermieden werden, damit die innere Komponente problemlos in andere Umgebungen integriert werden können.

gerahmt|links|Der VCLSD-Prozess mit Trennung in eine äußere und eine innere Komponente  

Beispiel „Spiel mit Highscore-Verwaltung“

Wenn man ein „Spiel mit Highscore-Verwaltung“ realisieren möchte, sollte man zwei unanhängige Komponenten schreiben: Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung. Eine dritte Komponenten, die so genannnte Rahmenkomponente verknüpft diese beiden Anwendungen.

Die Rahmenkomponente liest beispielsweise bei Spielende die erreichten Punkte aus dem Modell der Spielkomponente aus und leitet diese an das Highscore-Modell weiter. Eine weitere Möglichkeit wäre, dass die Rahmenkomponente ü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.

Implementierung

Das VCLSD-Pattern lässt sich auf mehrere Arten implementieren:

Quellen

Siehe auch


Dieser Artikel ist GlossarWiki-konform.