Logic-Data-View-Controller-Service-Paradigma: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{MVC:Menü}} | {{MVC:Menü}} | ||
=Definition | ==Definition ([[Kowarschick (MMProg)]])== | ||
[[ | [[Datei:LDVC-Module 01.png|gerahmt|rechts|LDVC-Module]] | ||
[[ | [[Datei:LDVCS-Module 01.png|gerahmt|rechts|LDVCS-Module]] | ||
Als [[Logic-Data-View-Controller-Service-Paradigma]] | Als [[Logic-Data-View-Controller-Service-Paradigma]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm|Logic-data-view-controller-service paradigm]]) oder | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm|Logic-data-view-controller-service paradigm]]) oder | ||
[[Logic-Data-View-Controller-Service-Paradigma|- | [[Logic-Data-View-Controller-Service-Paradigma|-Architektur]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm|architecture]]), | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm|architecture]]), | ||
kurz [[Logic-Data-View-Controller-Service-Paradigma|LDVCS-Paradigma]], [[Logic-Data-View-Controller-Service-Paradigma|LDVCS-Architektur]] | kurz [[Logic-Data-View-Controller-Service-Paradigma|LDVCS-Paradigma]], [[Logic-Data-View-Controller-Service-Paradigma|LDVCS-Architektur]] | ||
Zeile 17: | Zeile 17: | ||
und [[Logic-Data-View-Controller-Service-Paradigma/Data|Data]] (Daten). | und [[Logic-Data-View-Controller-Service-Paradigma/Data|Data]] (Daten). | ||
==Datenmodul== | ===Datenmodul=== | ||
Ein [[Logic-Data-View-Controller-Service-Paradigma/Data|Datenmodul]] | Ein [[Logic-Data-View-Controller-Service-Paradigma/Data|Datenmodul]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/data|LDVCS data module]]) | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/data|LDVCS data module]]) | ||
einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] | einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] | ||
dient zur Speicherung bestimmter Daten, | dient zur Speicherung bestimmter Daten, {{dh}} zur Speicherung von Teilen des aktuellen Zustands der Anwendung. | ||
Ein LDVCS-Datenmodul kann weitere Aufgaben übernehmen: | Ein LDVCS-Datenmodul kann weitere Aufgaben übernehmen: | ||
Zeile 28: | Zeile 28: | ||
* andere Module über Änderungen informieren (meist mittels des [[Observer-Pattern]]s) | * andere Module über Änderungen informieren (meist mittels des [[Observer-Pattern]]s) | ||
==View (Darstellung, Präsentation)== | ===View (Darstellung, Präsentation)=== | ||
[[Logic-Data-View-Controller-Service-Paradigma/View|LDVCS-Views]] | [[Logic-Data-View-Controller-Service-Paradigma/View|LDVCS-Views]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/view|LDVCS views]]) | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/view|LDVCS views]]) | ||
sind die grafischen, akustischen, haptischen und olfaktorischen | sind die grafischen, akustischen, haptischen und olfaktorischen Schnittstellen einer | ||
[[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | ||
Sie „visualisieren“ Daten, die in [[Logic-Data-View-Controller-Service-Paradigma/Data|Datenmodulen]] der Anwendung enthalten sind. | Sie „visualisieren“ Daten, die in [[Logic-Data-View-Controller-Service-Paradigma/Data|Datenmodulen]] der Anwendung enthalten sind. | ||
Zeile 40: | Zeile 40: | ||
* Benutzeraktionen, die über grafische Eingabeelemente – wie Textfelder oder Buttons – erfolgen, an einen [[Logic-Data-View-Controller-Service-Paradigma|Controller]] weiterleiten | * Benutzeraktionen, die über grafische Eingabeelemente – wie Textfelder oder Buttons – erfolgen, an einen [[Logic-Data-View-Controller-Service-Paradigma|Controller]] weiterleiten | ||
==Controller (Steuerung)== | ===Controller (Steuerung)=== | ||
[[Logic-Data-View-Controller-Service-Paradigma/Controller|LDVCS-Controller]] | [[Logic-Data-View-Controller-Service-Paradigma/Controller|LDVCS-Controller]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/controller|LDVCS controllers]]) dienen zur Steuerung einer | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/controller|LDVCS controllers]]) dienen zur Steuerung einer | ||
[[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | ||
Dazu nimmt ein Controller Eingaben aus verschiedensten Quellen entgegen ( | Dazu nimmt ein Controller Eingaben aus verschiedensten Quellen entgegen ({{zB}} 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 geeignete [[Logic-Data-View-Controller-Service-Paradigma/Logic|Logikmodule]] weiter. | ||
Ein LDVCS-Controller sollte keine weiteren Aufgaben übernehmen. | Ein LDVCS-Controller sollte keine weiteren Aufgaben übernehmen. | ||
==Logikmodul== | ===Logikmodul=== | ||
[[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Module]] | [[Logic-Data-View-Controller-Service-Paradigma/Logic|LDVCS-Logik-Module]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/logic|LDVCS logic modules]]) realisieren die | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/logic|LDVCS logic modules]]) realisieren die | ||
Anwendungslogik einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | Anwendungslogik einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]]. | ||
Ein Logikmodul reagiert auf | Ein Logikmodul reagiert auf Ereignisse, wie {{zB}} Benutzereingaben, Timer Events oder Ähnliches, | ||
indem es Daten in Datenmodulen entweder indirekt mit Hilfe von | indem es Daten in Datenmodulen entweder indirekt mit Hilfe von | ||
[[Logic-Data-View-Controller-Service-Paradigma/Service|Servicemodulen]] oder direkt manipuliert. | [[Logic-Data-View-Controller-Service-Paradigma/Service|Servicemodulen]] oder direkt manipuliert. | ||
Die Aktionen, die ein Logikmodul ausführt, hängen | Die Aktionen, die ein Logikmodul ausführt, hängen {{iAllg}} vom aktuellen [[Zustand]] der Anwendung ab. | ||
Dieser Zustand kann entweder in Datenmodulen gespeichert werden (so dass auch andere Module darauf zugreifen können) | Dieser Zustand kann entweder in Datenmodulen gespeichert werden (so dass auch andere Module darauf zugreifen können) | ||
oder im Logikmodul selbst (so dass ein Zugriff durch andere Module nicht möglich ist). | oder im Logikmodul selbst (so dass ein Zugriff durch andere Module nicht möglich ist). | ||
Ein LDVCS-Logik-Modul sollte keine weiteren Aufgaben übernehmen. | Ein LDVCS-Logik-Modul sollte keine weiteren Aufgaben übernehmen. | ||
==Service== | ===Service=== | ||
Ein [[Logic-Data-View-Controller-Service-Paradigma/Service|Service]] | Ein [[Logic-Data-View-Controller-Service-Paradigma/Service|Service]] | ||
(engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/service|service]]) | (engl. [[GlossaryWiki:Logic-data-view-controller-service paradigm/service|service]]) | ||
dient einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] zur Kommunikation | dient einer [[Logic-Data-View-Controller-Service-Paradigma|LDVCS]]-[[Anwendung]] zur Kommunikation | ||
mit der Außenwelt, | mit der Außenwelt, {{dh}} 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 [[Logic-Data-View-Controller-Service/Data|Datenmodulen]] auslesen und in externe | Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus [[Logic-Data-View-Controller-Service/Data|Datenmodulen]] auslesen und in externe | ||
[[Repository|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Datenmodule einfügen. | [[Repository|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Datenmodule einfügen. | ||
Ein LDVCS-Service-Modul sollte keine weiteren Aufgaben übernehmen. | Ein LDVCS-Service-Modul sollte keine weiteren Aufgaben übernehmen. | ||
==LDVCS-Paradigma: Varianten (Definitionen nach [[Kowarschick (MMProg)]])== | ===LDVCS-Paradigma: Varianten (Definitionen nach [[Kowarschick (MMProg)]])=== | ||
<gallery perrow="2" widths="301px" heights="410px" class="floatright"> | <gallery perrow="2" widths="301px" heights="410px" class="floatright"> | ||
Datei:VCLSD-Schichtenarchitektur 01 301px.png | Beispiel für eine VCLSD-Schichtenarchitektur | |||
Datei:VCLD-Schichtenarchitektur 01 301px.png | Beispiel für eine VCLD-Schichtenarchitektur | |||
</gallery> | </gallery> | ||
===VCLSD-Paradigma=== | ====VCLSD-Paradigma==== | ||
Ein LDVCS-Paradigma wird '''VCLSD-Paradigma''' genannt, wenn die fünf zugehörigen Module folgende Schichtenarchitektur bilden: | Ein LDVCS-Paradigma wird '''VCLSD-Paradigma''' genannt, wenn die fünf zugehörigen Module folgende Schichtenarchitektur bilden: | ||
''View'', ''Controller'', ''Logic'', ''Service'', ''Data''. | ''View'', ''Controller'', ''Logic'', ''Service'', ''Data''. | ||
Die fünf Module einer VCLSD-Komponente sind gemäß dem [[Schichtenparadigma]] in Ebenen angeordnet. | Die fünf Module einer VCLSD-Komponente sind gemäß dem [[Schichtenparadigma]] in Ebenen angeordnet. | ||
Die höheren Ebenen können auf | Die höheren Ebenen können auf tiefer gelegene Ebenen zugreifen, aber nicht umgekehrt. | ||
Die | Die unterste Ebene ist Data. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit | ||
indirekt – | indirekt – {{zB}} durch Antworten auf [[Nachricht]]en oder mit Hilfe des [[Observer-Pattern]]s – kommunizieren. | ||
Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese zugreifen | Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese zugreifen | ||
(sowie | (sowie {{iAllg}} auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt). | ||
Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel | Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel | ||
um Daten aus einer externen Quelle zu laden, oder um zu überprüfen, | um Daten aus einer externen Quelle zu laden, oder um zu überprüfen, | ||
ob die entsprechenden Zugriffsrechte für eine Datenmanipulation | ob die entsprechenden Zugriffsrechte für eine Datenmanipulation überhaupt gegeben sind). | ||
Ein | Ein Controller-Modul kann nur auf Logikmodule zugreifen, um Benutzeraktionen an dieses (bereinigt und normalisiert) weiterzuleiten. | ||
Direkte Zugriffe auf Service- und Datenmodule wären zwar möglich, sind aber nicht vorgesehen. | Direkte Zugriffe auf Service- und Datenmodule wären zwar möglich, sind aber nicht vorgesehen. | ||
Eine View kommuniziert | Eine View kommuniziert {{iAllg}} direkt nur mit Controller-Modulen, um diesen 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, | Ein direkter Zugriff auf ein Datenmodul ist nur dann notwendig, wenn die Nachrichten, die von den Datenmodulen verschickt werden, | ||
nicht alle relevanten Informationen enthalten. Zugriffe auf andere Module sind nicht vorgesehen. | nicht alle relevanten Informationen enthalten. Zugriffe auf andere Module sind nicht vorgesehen. | ||
Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und | Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controller-Modulen. | ||
===LDVCS-Multicast-Paradigma=== | ====LDVCS-Multicast-Paradigma==== | ||
Ein LDVCS-Paradigma wird LDVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, | Ein LDVCS-Paradigma wird LDVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, {{dh}} mit Hilfe | ||
von [[Multicast-Nachricht]]en kommunizieren. | von [[Multicast-Nachricht]]en kommunizieren. | ||
==LDVCS-Pattern (Definitionen nach [[Kowarschick (MMProg)]])== | ===LDVCS-Pattern (Definitionen nach [[Kowarschick (MMProg)]])=== | ||
Wenn für ein LDVCS-Paradigma – im Sinne eines [[Entwurfmusters]] – eine konkrete [[Klasse]]n- und [[Objekt]]-Struktur für die | Wenn für ein LDVCS-Paradigma – im Sinne eines [[Entwurfmusters]] – eine konkrete [[Klasse]]n- und [[Objekt]]-Struktur für die | ||
Zeile 121: | Zeile 120: | ||
vorgegeben ist, spricht man von einem [[Logic-Data-View-Controller-Service-Pattern|LDVCS-Pattern]]. | vorgegeben ist, spricht man von einem [[Logic-Data-View-Controller-Service-Pattern|LDVCS-Pattern]]. | ||
===VCLSD-Pattern=== | ====VCLSD-Pattern==== | ||
Ein LDVCS-Pattern, das ein VCLSD-Paradigma realisiert, wird auch '''VCLSD-Pattern''' genannt. | Ein LDVCS-Pattern, das ein VCLSD-Paradigma realisiert, wird auch '''VCLSD-Pattern''' genannt. | ||
===LDVCS-Multicast-Pattern=== | ====LDVCS-Multicast-Pattern==== | ||
Ein LDVCS-Pattern, das nur auf Multicast-Nachrichten basiert, wird auch '''LDVCS-Multicast-Pattern''' genannt. | Ein LDVCS-Pattern, das nur auf Multicast-Nachrichten basiert, wird auch '''LDVCS-Multicast-Pattern''' genannt. | ||
=Das VCLSD-Paradigma als Verfeinerung des MVCS-Paradigmas= | ==Das VCLSD-Paradigma als Verfeinerung des MVCS-Paradigmas== | ||
Dieses Pattern ist eine Verfeinerung des [[Model-View-Controller-Service-Paradigma]]s (MVCS-Paradigma). | Dieses Pattern ist eine Verfeinerung des [[Model-View-Controller-Service-Paradigma]]s (MVCS-Paradigma). | ||
Zeile 139: | Zeile 138: | ||
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). | ||
= Der VCLSD-Prozess = | == Der VCLSD-Prozess == | ||
[[ | [[Datei:VCLD-Prozess 01.png|gerahmt||rechts|Der VCLD-Prozess]] | ||
[[Datei:VCLSD-Prozess 01.png|gerahmt||rechts|Der VCLSD-Prozess]] | |||
== Beispiel Jump 'n' Run== | === Beispiel Jump 'n' Run=== | ||
In einem [[Jump 'n' Run|Jump-'n'-Run]]-Spiel werden Daten ('''Data''') über | In einem [[Jump 'n' Run|Jump-'n'-Run]]-Spiel werden Daten ('''Data''') über | ||
die Spielfigur (Position, Laufrichtung, Geschwindigkeit ...), die Gegner, die Gegenstände etc. gespeichert. | die Spielfigur (Position, Laufrichtung, Geschwindigkeit ...), die Gegner, die Gegenstände etc. gespeichert. | ||
Zeile 153: | Zeile 153: | ||
zur Manipulation der Spielfigur an die Logik-Komponente ('''Logic''') weitergeleitet. | zur Manipulation der Spielfigur an die Logik-Komponente ('''Logic''') weitergeleitet. | ||
Man beachte, dass die Logik-Komponente | Man beachte, dass die Logik-Komponente {{iAllg}} aktiv sein kann: Sie kann die Daten selbstständig, {{dh}} auch ohne Manipulation durch den | ||
Controller verändern. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, direkt von der Logik-Komponente gesteuert. | 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. | Mit Hilfe einer Service-Komponente ('''Service''') kann das Spiel zu einem Multiuser-Spiel erweitert werden. | ||
Die Service-Komponente hat dann zwei Aufgaben: | Die Service-Komponente hat dann zwei Aufgaben: | ||
# Die Position des Avatars ( | # Die Position des Avatars ({{dh}} der eigenen Spielfigur) an einen zentralen Server zu übertragen. | ||
# Die | # Die Position 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. | 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 | Zu diesem Zweck sollten die Service-Komponente eine Initialisierungsmethode implementieren, die | ||
vom Hauptprogramm direkt aufgerufen wird, nachdem die Daten- und die Service- | vom Hauptprogramm direkt aufgerufen wird, nachdem die Daten- und die Service-Komponente erzeugt wurden. | ||
=== Modularität === | ==== Modularität ==== | ||
Der große Vorteil des VCLSD-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 | wird hierbei beachtet: 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. | 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 eines der fünf Module: | Jede der folgenden Änderungen hat lediglich Auswirkungen auf eines der fünf Module: | ||
# Änderung der Darstellung ( | # Änderung der Darstellung ({{dh}} der View): Die View kann jederzeit durch neue [[Skin]]s 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. | ||
# Änderung der Spielsteuerung ( | # Änderung der Spielsteuerung ({{dh}} 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 {{zB}} Kollisionen) per [[Force Feedback]] an den Benutzer zurückmeldet. Dazu muss sich der Controller ebenfalls über Datenänderungen informieren lassen. | ||
# Änderung der Spiellogik ( | # Änderung der Spiellogik ({{dh}} der Logikkomponente): Die KI-Engine zur Steuerung der Gegner kann beispielsweise durch eine bessere Engine ersetzt werden. | ||
# Änderung der Dateninitialisierung ( | # Änderung der Dateninitialisierung ({{dh}} der Service-Komponente): Wenn die Dateninitialisierung künftig beispielsweise nicht mehr über XML, sondern über SQL erfolgen soll, muss lediglich die entsprechende Service-Komponente ausgetauscht werden. | ||
# Änderung des Spielservers ( | # Änderung des Spielservers ({{dh}} 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 | Auch die Datenkomponente kann ausgetauscht werden, wenn {{zB}} andere Datenstrukturen zur Speicherung der Daten eingesetzt werden sollen. | ||
Es ist darüber hinaus möglich, einer Datenkomponente | Es ist darüber hinaus möglich, einer Datenkomponente {{zB}} mit Hilfe von speziellen Filter-Services Filter vorzuschalten (vgl. [[Aspektorientierte Programmierung]]). Zum Beispiel kann auf diese Weise ein Login-Mechanismus realisiert werden: | ||
Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich | Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich abgeschlossen wurde. | ||
= Verfeinerung des VCLSD-Prozesses= | == Verfeinerung des VCLSD-Prozesses== | ||
Genauso wie der [[Model-View-Controller-Paradigma|MVC-Prozess]] und der [[Model-View-Controller-Service-Paradigma|MVCS-Prozess]] kann auch der VCLSD-Prozess verfeinert werden. Auch hier | Genauso wie der [[Model-View-Controller-Paradigma|MVC-Prozess]] und der [[Model-View-Controller-Service-Paradigma|MVCS-Prozess]] kann auch der VCLSD-Prozess verfeinert werden. Auch hier | ||
kann eine „äußere VCLSD-Komponente“ eine „innere VCLSD-Komponente“ verwenden: | kann eine „äußere VCLSD-Komponente“ eine „innere VCLSD-Komponente“ verwenden: | ||
Zeile 189: | Zeile 189: | ||
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. | ||
[[ | [[Datei: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“=== | ||
Wenn man ein „Spiel mit Highscore-Verwaltung“ realisieren möchte, sollte man zwei | Wenn man ein „Spiel mit Highscore-Verwaltung“ realisieren möchte, sollte man zwei unabhängige Komponenten implementieren: | ||
Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung. | Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung. | ||
Eine dritte Komponente, die | Eine dritte Komponente, die sogenannte Rahmenkomponente verknüpft diese beiden Anwendungen. | ||
Die Rahmenkomponente liest beispielsweise bei | Die Rahmenkomponente liest beispielsweise bei | ||
Spielende die erreichten Punkte aus dem Modell der Spielkomponente aus und leitet diese an das Highscore-Modell weiter. | Spielende die erreichten Punkte aus dem Modell der Spielkomponente aus und leitet diese an das Highscore-Modell weiter. | ||
Zeile 201: | Zeile 201: | ||
ob der Spieler schon mindestens fünf Level erfolgreich gespielt hat. Nur in diesem Fall gewährt sie den Zugang zum Trainingsmodus des Spiels. | 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= | ==Implementierung== | ||
Das VCLSD-Pattern lässt sich auf mehrere Arten implementieren: | Das VCLSD-Pattern lässt sich auf mehrere Arten implementieren: | ||
* [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Dependency Injection| | * [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Dependency Injection|Initialisierung mittels Dependency Injection]] | ||
* [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Singleton| | * [[View-Controller-Logic-Service-Data-Pattern/Implementierung: Singleton|Initialisierung mittels Singletons]] | ||
* [[View-Controller-Logic-Service-Data-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> | ||
==Data Access Object== | ===Data Access Object=== | ||
{{TBD}} | {{TBD}} | ||
=Quellen= | ==Quellen== | ||
# {{Quelle|Kowarschick, W.: Multimedia-Programmierung}} | # {{Quelle|Kowarschick, W.: Multimedia-Programmierung}} | ||
=Siehe auch= | ==Siehe auch== | ||
*{{Vgl|Model-View-Controller-Paradigma}} | *{{Vgl|Model-View-Controller-Paradigma}} | ||
*{{Vgl|Model-View-Controller-Service-Paradigma}} | *{{Vgl|Model-View-Controller-Service-Paradigma}} |
Aktuelle Version vom 22. September 2017, 16:49 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.
Model (Data) | View | Controller |
|||
Definition (Kowarschick (MMProg))
![](/w/media/3/37/LDVC-Module_01.png)
![](/w/media/1/18/LDVCS-Module_01.png)
Als Logic-Data-View-Controller-Service-Paradigma (engl. Logic-data-view-controller-service paradigm) oder -Architektur (engl. architecture), kurz LDVCS-Paradigma, LDVCS-Architektur oder auch nur LDVCS bezeichnet man ein Architekturmuster, bei der eine Anwendungs-Komponente in fünf eigenständige Module unterteilt wird: View (Darstellung, Präsentation), Controller (Steuerung), Logic (Logik), Service (Service, Zugriff auf externe Daten) und Data (Daten).
Datenmodul
Ein Datenmodul (engl. LDVCS data module) einer LDVCS-Anwendung dient zur Speicherung bestimmter Daten, d. h. zur Speicherung von Teilen des aktuellen Zustands der Anwendung.
Ein LDVCS-Datenmodul kann weitere Aufgaben übernehmen:
- anderen Modulen Zugriff auf die Zustandsdaten gewähren
- andere Module über Änderungen informieren (meist mittels des Observer-Patterns)
View (Darstellung, Präsentation)
LDVCS-Views (engl. LDVCS views) sind die grafischen, akustischen, haptischen und olfaktorischen Schnittstellen einer LDVCS-Anwendung. Sie „visualisieren“ Daten, die in Datenmodulen der Anwendung enthalten sind.
Eine LDVCS-View kann weitere Aufgaben übernehmen:
- bei Daten-Änderungen in den zugehörigen Datenmodulen 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 (Steuerung)
LDVCS-Controller (engl. LDVCS controllers) dienen zur Steuerung einer LDVCS-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 geeignete Logikmodule weiter.
Ein LDVCS-Controller sollte keine weiteren Aufgaben übernehmen.
Logikmodul
LDVCS-Logik-Module (engl. LDVCS logic modules) realisieren die Anwendungslogik einer LDVCS-Anwendung.
Ein Logikmodul reagiert auf Ereignisse, wie z. B. Benutzereingaben, Timer Events oder Ähnliches, indem es Daten in Datenmodulen entweder indirekt mit Hilfe von Servicemodulen oder direkt manipuliert.
Die Aktionen, die ein Logikmodul ausführt, hängen i. Allg. vom aktuellen Zustand der Anwendung ab. Dieser Zustand kann entweder in Datenmodulen gespeichert werden (so dass auch andere Module darauf zugreifen können) oder im Logikmodul selbst (so dass ein Zugriff durch andere Module nicht möglich ist).
Ein LDVCS-Logik-Modul sollte keine weiteren Aufgaben übernehmen.
Service
Ein Service (engl. service) dient einer LDVCS-Anwendung 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 Datenmodulen auslesen und in externe Repositories schreiben, als auch Daten aus externen Repositories lesen und in Datenmodule einfügen.
Ein LDVCS-Service-Modul sollte keine weiteren Aufgaben übernehmen.
LDVCS-Paradigma: Varianten (Definitionen nach Kowarschick (MMProg))
-
Beispiel für eine VCLSD-Schichtenarchitektur
-
Beispiel für eine VCLD-Schichtenarchitektur
VCLSD-Paradigma
Ein LDVCS-Paradigma wird VCLSD-Paradigma genannt, wenn die fünf zugehörigen Module folgende Schichtenarchitektur bilden: View, Controller, Logic, Service, Data.
Die fünf Module einer VCLSD-Komponente sind gemäß dem Schichtenparadigma in Ebenen angeordnet. Die höheren Ebenen können auf tiefer gelegene Ebenen zugreifen, aber nicht umgekehrt.
Die unterste Ebene ist Data. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit indirekt – z. B. durch Antworten auf Nachrichten oder mit Hilfe des Observer-Patterns – kommunizieren.
Ein Servicemodul kennt nur die darunterliegende Datenmodule und kann nur auf diese zugreifen (sowie i. Allg. auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).
Ein Logikmodul kann entweder direkt auf ein Datenmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel um Daten aus einer externen Quelle zu laden, oder um zu überprüfen, ob die entsprechenden Zugriffsrechte für eine Datenmanipulation überhaupt gegeben sind).
Ein Controller-Modul kann nur auf Logikmodule zugreifen, um Benutzeraktionen an dieses (bereinigt und normalisiert) weiterzuleiten. Direkte Zugriffe auf Service- und Datenmodule wären zwar möglich, sind aber nicht vorgesehen.
Eine View kommuniziert i. Allg. direkt nur mit Controller-Modulen, um diesen 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. Zugriffe auf andere Module sind nicht vorgesehen.
Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controller-Modulen.
LDVCS-Multicast-Paradigma
Ein LDVCS-Paradigma wird LDVCS-Multicast-Paradigma genannt, wenn alle Module nur indirekt, d. h. mit Hilfe von Multicast-Nachrichten kommunizieren.
LDVCS-Pattern (Definitionen nach Kowarschick (MMProg))
Wenn für ein LDVCS-Paradigma – im Sinne eines Entwurfmusters – eine konkrete Klassen- und Objekt-Struktur für die fünf Module Data, Logic, View, Controller und Service vorgegeben ist, spricht man von einem LDVCS-Pattern.
VCLSD-Pattern
Ein LDVCS-Pattern, das ein VCLSD-Paradigma realisiert, wird auch VCLSD-Pattern genannt.
LDVCS-Multicast-Pattern
Ein LDVCS-Pattern, das nur auf Multicast-Nachrichten basiert, wird auch LDVCS-Multicast-Pattern genannt.
Das VCLSD-Paradigma als Verfeinerung des MVCS-Paradigmas
Dieses Pattern ist eine Verfeinerung des Model-View-Controller-Service-Paradigmas (MVCS-Paradigma).
Eine VCLSD-Komponente besteht im Gegensatz zum MVCS-Komponenten nicht aus vier, sondern aus fünf Modulen. Der Grund dafür ist, dass das Modell des MVCS-Paradigmas normalerweise zwei Aufgaben übernimmt: Die Speicherung der Anwendungsdaten und die Realisierung der Anwendungslogik. Häufig übernimmt auch der Controller die Realisierung der Anwendungslogik.
Im VCLSD-Paradigma 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 VCLSD-Prozess
![](/w/media/f/fe/VCLD-Prozess_01.png)
![](/w/media/a/aa/VCLSD-Prozess_01.png)
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 Manipulation 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:
- Die Position des Avatars (d. h. der eigenen Spielfigur) an einen zentralen Server zu übertragen.
- Die Position 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-Komponente erzeugt wurden.
Modularität
Der große Vorteil des VCLSD-Patterns ist die Modularität. Das Prinzip „Separation of Concerns“ wird hierbei beachtet: 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 eines der fünf Module:
- Ä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.
- Ä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.
- Änderung der Spiellogik (d. h. der Logikkomponente): Die KI-Engine zur Steuerung der Gegner kann beispielsweise durch eine bessere Engine ersetzt werden.
- Änderung der Dateninitialisierung (d. h. der Service-Komponente): Wenn die Dateninitialisierung künftig beispielsweise nicht mehr über XML, sondern über SQL erfolgen soll, muss lediglich die entsprechende Service-Komponente ausgetauscht werden.
- Ä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 z. B. mit Hilfe von speziellen Filter-Services Filter vorzuschalten (vgl. Aspektorientierte Programmierung). Zum Beispiel kann auf diese Weise ein Login-Mechanismus realisiert werden: Der Zugriff auf bestimmte Daten wird erst dann erlaubt, wenn ein Login-Vorgang erfolgreich abgeschlossen 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.
![](/w/media/9/90/VCLSD-Prozess_02.png)
Beispiel „Spiel mit Highscore-Verwaltung“
Wenn man ein „Spiel mit Highscore-Verwaltung“ realisieren möchte, sollte man zwei unabhängige Komponenten implementieren: Das Spiel selbst und eine spielunabhängige Highscore-Verwaltung.
Eine dritte Komponente, die sogenannte 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:
- Initialisierung mittels Dependency Injection
- Initialisierung mittels Singletons
- Kommunikation ausschließlich mittels des Observer Patterns
Data Access Object
TO BE DONE
Quellen
- Kowarschick (MMProg): Wolfgang Kowarschick; Vorlesung „Multimedia-Programmierung“; Hochschule: Hochschule Augsburg; Adresse: Augsburg; Web-Link; 2018; Quellengüte: 3 (Vorlesung)