Logic-Data-View-Controller-Service-Paradigma: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) |
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
=Definition= | =Definition= | ||
Das [[Logic-Data-View-Controller-Services-Paradigma]] oder [[Logic-Data-View-Controller-Services-Paradigma|-Pattern]], kurz [[LDVCS]], bezeichnet ein [[Architekturmuster]] zur Trennung einer [[Anwendung]] in drei separate Einheiten: | Das [[Logic-Data-View-Controller-Services-Paradigma]] oder [[Logic-Data-View-Controller-Services-Paradigma|-Pattern]], kurz [[LDVCS]], bezeichnet ein [[Architekturmuster]] zur Trennung einer [[Anwendung]] in drei separate Einheiten: | ||
| Zeile 53: | Zeile 51: | ||
Lediglich die Datenkomponente wird im Allgemeinen nicht ausgetauscht, sondern höchstens erweitert. Allerdings ist es denkbar, | Lediglich die Datenkomponente wird im Allgemeinen nicht ausgetauscht, sondern höchstens erweitert. Allerdings ist es denkbar, | ||
Filter vorzuschalten, die einen Zugriff auf bestimmte Daten erst dann erlauben, wenn beispielsweise ein Login-Vorgang erfolgreich abgschlossen wurde. | Filter vorzuschalten, die einen Zugriff auf bestimmte Daten erst dann erlauben, wenn beispielsweise ein Login-Vorgang erfolgreich abgschlossen wurde. | ||
= Verfeinerung des LDVCS-Prozesses= | |||
Genauso wie der [[Model-View-ControllerProzess|MVC-Prozess]] und der [[Model-View-Controller-Service-Prozess|MVCS-Prozess]] kann auch der LDVCS-Prozess verfeinert werden. Auch hier bietet sich die Aufteilung | |||
in Kernawendungen (Domains) und eine Rahmenanwendung (Frame) an, die den Zugang zu den Kernanwendungen steuert. | |||
In diesem Fall gibt es mehrere relativ unabhängige LDVCS-Prozesse: Die Rahmenkomponente darf auf zugehörigen Kernkomponenten zugreifen. | |||
Der umgekehrte Weg sollte allerdings vermieden werden, damit die Kernanwendungen problemlos in andere Umgebungen integriert werden können. | |||
[[Medium:LDVCS-Prozess 01.png|gerahmt|links|LDVCS-Prozess 2 (mit Trennung in Frame und Domain)]] | |||
=Quellen= | =Quellen= | ||
Version vom 22. Dezember 2010, 14:46 Uhr
Definition
Das Logic-Data-View-Controller-Services-Paradigma oder -Pattern, kurz LDVCS, bezeichnet ein Architekturmuster zur Trennung einer Anwendung in drei separate Einheiten: Logic (Logik), Data (Daten), View (Darstellung), Controller (Steuerung) und Service (Service).
Konzept
gerahmt||rechts|LDVCS-Prozess Dieses Paradigma ist eine Verfeinerung des Model-View-Controller-Services-Paradigmas.
Die Model-Komponente des MVCS-Paradigmas übernimmt normalerweise zwei Aufgaben: Die Speicherung der Anwendungsdaten und die Realisierung der Anwendungslogik. Daher wird im LDVCS-Paradigma das Model in zwei Bestandteile zerlegt: Die Daten-Komponente (Data) und die Logik-Komponente (Logic).
Der LDVCS-Prozess
Beispiel Jump 'n' Run
In einem Jump-'n'-Run-Spiel werden Daten (Data) über die Spielfigur (Position, Laufrichtiung, 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:
- Die Position des Avatars (d.h. der eigenen Spielfigur) an einen zentralen Server zu übertragen.
- 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 Servic-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 LDVCS-Paradigmas ist die Modularität. Das Prinzip „Separation of Concerns“ wird hierbei bachtet: Jede Aufgabe wird von einer eigenen Komponente bearbeitet.
Ein Jump'n'Run-Spiel beispielsweise, das derartig modular aufgebaut ist, kann sehr leicht an neue Gegebenheiten angepasst werden. Jede der folgenden Änderungen hat lediglich Auswirkungen auf eine der fünf Komponenten:
- Ä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.
- Änderung der Spiellogik (d.h. der Logikkomponente): Die KI-Engine zur Steuerung der Gegener kann beispielsweise durch eine bessere Engine ersetzt werden.
- Ä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.
- Ä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 zulassen.
Lediglich die Datenkomponente wird im Allgemeinen nicht ausgetauscht, sondern höchstens erweitert. Allerdings ist es denkbar, Filter vorzuschalten, die einen Zugriff auf bestimmte Daten erst dann erlauben, wenn beispielsweise ein Login-Vorgang erfolgreich abgschlossen wurde.
Verfeinerung des LDVCS-Prozesses
Genauso wie der MVC-Prozess und der MVCS-Prozess kann auch der LDVCS-Prozess verfeinert werden. Auch hier bietet sich die Aufteilung in Kernawendungen (Domains) und eine Rahmenanwendung (Frame) an, die den Zugang zu den Kernanwendungen steuert. In diesem Fall gibt es mehrere relativ unabhängige LDVCS-Prozesse: Die Rahmenkomponente darf auf zugehörigen Kernkomponenten zugreifen. Der umgekehrte Weg sollte allerdings vermieden werden, damit die Kernanwendungen problemlos in andere Umgebungen integriert werden können.
gerahmt|links|LDVCS-Prozess 2 (mit Trennung in Frame und Domain)
