Model-View-Controller-Paradigma - Versionsgeschichte

Kowa: /* Beispiel „Advanture Game“ */

2020-05-14T07:10:20Z

Beispiel „Advanture Game“

← Nächstältere Version		Version vom 14. Mai 2020, 07:10 Uhr
Zeile 222:		Zeile 222:
	Zum Beispiel kann sie veranlassen, dass die aktuelle Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geändert wird.		Zum Beispiel kann sie veranlassen, dass die aktuelle Auswahl des Warenkataloges den Wünschen des Benutzers gemäß geändert wird.

	====Beispiel ~~„Advanture~~ Game“====		====Beispiel „Adventure Game“====
	In einem Abenteuerspiel wird häufig sowohl die aktuelle Szene, als auch eine Übersichtskarte mit allen		In einem Abenteuerspiel wird häufig sowohl die aktuelle Szene, als auch eine Übersichtskarte mit allen
	bereits erkundeten Bereichen visualisiert. Wenn an diesem Spiel mehr als ein Spieler beteiligt sind, gibt es		bereits erkundeten Bereichen visualisiert. Wenn an diesem Spiel mehr als ein Spieler beteiligt sind, gibt es
	sogar zahlreiche verschiedene Visualisierungen (aus Sicht eines jeden Spielers mindestens eine!).		sogar zahlreiche verschiedene Visualisierungen (aus Sicht eines jeden Spielers mindestens eine!).

	Hier wäre eine direkte Kommunikation zwischen Modell und View extrem unpraktisch.		Hier wäre eine direkte Kommunikation zwischen Modell und View extrem unpraktisch.

	====Kommunikation zwischen zwei VCM-Komponenten====		====Kommunikation zwischen zwei VCM-Komponenten====

Kowa am 22. September 2017 um 15:02 Uhr

2017-09-22T15:02:13Z

← Nächstältere Version		Version vom 22. September 2017, 15:02 Uhr
Zeile 383:		Zeile 383:
	<li>{{Quelle\|Stoiber, D. (2005): Implementierung des Model-View-Controller Paradigmas}}</li>		<li>{{Quelle\|Stoiber, D. (2005): Implementierung des Model-View-Controller Paradigmas}}</li>
	<li>[http://www.martinfowler.com/eaaDev/uiArchs.html Martin Fowler: GUI Architectures]</li>		<li>[http://www.martinfowler.com/eaaDev/uiArchs.html Martin Fowler: GUI Architectures]</li>
	~~<li>[[WikipediaEN:Model–view–controller]]</li>~~
	~~<li>[[Wikipedia:Model View Controller]]</li>~~
	</ol>		</ol>

Zeile 394:		Zeile 392:
	*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]		*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]
	*[[Wikipedia:Model View_Controller]]		*[[Wikipedia:Model View_Controller]]
			*[[WikipediaEN:Model–view–controller]]
	*{{Quelle\|Berkovitz (2006)}}<noinclude>		*{{Quelle\|Berkovitz (2006)}}<noinclude>
	[[Kategorie:MVC]]		[[Kategorie:MVC]]

Kowa am 22. September 2017 um 14:59 Uhr

2017-09-22T14:59:21Z

← Nächstältere Version		Version vom 22. September 2017, 14:59 Uhr
Zeile 323:		Zeile 323:
	Diese Methode hat Zugriff auf die vom Benutzer übergebenen Daten, kann diese Daten in		Diese Methode hat Zugriff auf die vom Benutzer übergebenen Daten, kann diese Daten in
	ein Modell eintragen oder anderweitig verarbeiten und liefert schließlich einen Ergebnis-String.		ein Modell eintragen oder anderweitig verarbeiten und liefert schließlich einen Ergebnis-String.
	Abhängig vom Wert dieses ~~String~~ wird ~~eine~~ in der <code>struts.xml</code> spezifizierte View generiert.		Abhängig vom Wert dieses Strings (<code>input</code> oder <code>success</code>) wird die in der <code>struts.xml</code> spezifizierte View generiert.

	Ein anderes Beispiel ist das Web MVC Framework von Spring<ref>[http://static.springsource.org/spring/docs/2.0.7/reference/mvc.html Spring Framework: Chapter 13. Web MVC framework]</ref>. Hier nimmt der so genannte Front Controller die Anfragen (Requests) vom Client entgegen und		Ein anderes Beispiel ist das Web MVC Framework von Spring<ref>[http://static.springsource.org/spring/docs/2.0.7/reference/mvc.html Spring Framework: Chapter 13. Web MVC framework]</ref>. Hier nimmt der so genannte Front Controller die Anfragen (Requests) vom Client entgegen und

Kowa am 22. September 2017 um 14:54 Uhr

2017-09-22T14:54:45Z

Kowa am 22. September 2017 um 14:42 Uhr

2017-09-22T14:42:57Z

Kowa am 22. September 2017 um 14:41 Uhr

2017-09-22T14:41:27Z

Kowa am 22. September 2017 um 14:30 Uhr

2017-09-22T14:30:43Z

← Nächstältere Version		Version vom 22. September 2017, 14:30 Uhr
Zeile 394:		Zeile 394:
	*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]		*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]
	*[[Wikipedia:Model View_Controller]]		*[[Wikipedia:Model View_Controller]]
	*~~[http://joeberkovitz.com/blog/reviewtube/ Joe~~ Berkovitz~~: MVCS]~~<noinclude>		*{{Quelle\|Berkovitz (2006)}}<noinclude>
	[[Kategorie:MVC]]		[[Kategorie:MVC]]
	[[Kategorie:Objektorientierte Programmierung]]		[[Kategorie:Objektorientierte Programmierung]]

Kowa am 22. September 2017 um 14:06 Uhr

2017-09-22T14:06:43Z

← Nächstältere Version		Version vom 22. September 2017, 14:06 Uhr
Zeile 388:		Zeile 388:

	==Siehe auch==		==Siehe auch==
	#{{Vgl\|Model-View-Controller-Paradigma/Umsetzungen}}		*{{Vgl\|Model-View-Controller-Paradigma/Umsetzungen}}
	#{{Vgl\|Model-View-Controller-Service-Paradigma}}		*{{Vgl\|Model-View-Controller-Service-Paradigma}}
	#{{Vgl\|Logic-Data-View-Controller-Service-Paradigma}}		*{{Vgl\|Logic-Data-View-Controller-Service-Paradigma}}
	#[http://heim.ifi.uio.no/~trygver/index.html Homepage von Trygve M. H. Reenskaug, Erfinder von MVC]		*[http://heim.ifi.uio.no/~trygver/index.html Homepage von Trygve M. H. Reenskaug, Erfinder von MVC]
	#[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]		*[http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html Reenskaugs eigene Seite über MVC ]
	#[[Wikipedia:Model View_Controller]]		*[[Wikipedia:Model View_Controller]]
	#[http://joeberkovitz.com/blog/reviewtube/ Joe Berkovitz: MVCS]<noinclude>		*[http://joeberkovitz.com/blog/reviewtube/ Joe Berkovitz: MVCS]<noinclude>
	[[Kategorie:MVC]]		[[Kategorie:MVC]]
	[[Kategorie:Objektorientierte Programmierung]]		[[Kategorie:Objektorientierte Programmierung]]

Kowa: /* MVC-Prozesse (Definitionen nach Kowarschick (MMProg)) */

2016-08-16T09:22:23Z

MVC-Prozesse (Definitionen nach Kowarschick (MMProg))

← Nächstältere Version		Version vom 16. August 2016, 09:22 Uhr
Zeile 125:		Zeile 125:
	Ein MVC-Pattern, das nur auf Multicast-Nachrichten basiert, wird auch '''MVC-Multicast-Pattern''' genannt.		Ein MVC-Pattern, das nur auf Multicast-Nachrichten basiert, wird auch '''MVC-Multicast-Pattern''' genannt.

	= MVC-Prozesse (Definitionen nach [[Kowarschick (MMProg)]])=		== MVC-Prozesse (Definitionen nach [[Kowarschick (MMProg)]])==
	[[Datei:MVC-Prozess 01.png\|gerahmt\|rechts\|MVC-Prozess (in Anlehnung an [[Reenskaug (2003)]], Slide 17 auf Seite 10, sowie [[Commons:File:MVC-Process.svg]])]]		[[Datei:MVC-Prozess 01.png\|gerahmt\|rechts\|MVC-Prozess (in Anlehnung an [[Reenskaug (2003)]], Slide 17 auf Seite 10, sowie [[Commons:File:MVC-Process.svg]])]]
	Die Aufgaben, die die einzelnen Module des MVC-Paradigmas wahrnehmen, lassen sich als Interaktionsprozesse zwischen diesen Modulen darstellen.		Die Aufgaben, die die einzelnen Module des MVC-Paradigmas wahrnehmen, lassen sich als Interaktionsprozesse zwischen diesen Modulen darstellen.

Kowa am 16. August 2016 um 09:21 Uhr

2016-08-16T09:21:54Z

Änderungen zeigen

← Nächstältere Version		Version vom 22. September 2017, 14:54 Uhr
Zeile 149:		Zeile 149:
	=== Erweiterung des MVC-Prozesses===		=== Erweiterung des MVC-Prozesses===
	[[Datei:MVC-Prozess 02.png\|gerahmt\|rechts\|MVC-Prozess 2 (mit erweiterter Interaktion)]]		[[Datei:MVC-Prozess 02.png\|gerahmt\|rechts\|MVC-Prozess 2 (mit erweiterter Interaktion)]]
	Im zurvor beschriebenen MVC-Prozess kommuniziert der Benutzer direkt mit einer Steuerkomponente. Dies ist ~~z.B.~~ bei einer Tastatur-Steuerung, bei Verwendung von [[Webcam]] und Mikrofon oder bei einer Kommunikation über eine Daten-Schnittstelle (wie ~~z.B.~~ eine [[serielle Schnittstelle]] oder einen [[USB-Controller]]) möglich.		Im zurvor beschriebenen MVC-Prozess kommuniziert der Benutzer direkt mit einer Steuerkomponente. Dies ist {{zB}} bei einer Tastatur-Steuerung, bei Verwendung von [[Webcam]] und Mikrofon oder bei einer Kommunikation über eine Daten-Schnittstelle (wie {{zB}} eine [[serielle Schnittstelle]] oder einen [[USB-Controller]]) möglich.

	Meist werden jedoch dem Benutzer Interaktionselemente (wie Button, Slider und Texteingabe-Felder) über eine View präsentiert. In so einem Fall sollte die Darstellungkomponete die Benutzereingaben nicht selbst verarbeiten, sondern an ein zuständiges Steuerungsmodul weiterleiten.		Meist werden jedoch dem Benutzer Interaktionselemente (wie Button, Slider und Texteingabe-Felder) über eine View präsentiert. In so einem Fall sollte die Darstellungkomponete die Benutzereingaben nicht selbst verarbeiten, sondern an ein zuständiges Steuerungsmodul weiterleiten.
Zeile 155:		Zeile 155:
	Eine weitere Verfeinerung des zuvor beschriebenen Prozessablaufs wird bei der Kommunikation zwischen Modell und Controller vorgenommen:		Eine weitere Verfeinerung des zuvor beschriebenen Prozessablaufs wird bei der Kommunikation zwischen Modell und Controller vorgenommen:
	Das Modell kann nicht nur die View, sondern auch die auch		Das Modell kann nicht nur die View, sondern auch die auch
	die Steuerung direkt über Änderungen informieren, damit dieser dem User gegebenfalls ein Feedback (~~z.B.~~ [[Force Feedback]]) geben kann. Hier		die Steuerung direkt über Änderungen informieren, damit dieser dem User gegebenfalls ein Feedback ({{zB}} [[Force Feedback]]) geben kann. Hier
	kann man allerdings auch argumentieren, dass diese Art der Informations-„Visualisierung“ Aufgabe einer View wäre. Das heißt,		kann man allerdings auch argumentieren, dass diese Art der Informations-„Visualisierung“ Aufgabe einer View wäre. Das heißt,
	im Allgemeinen kann die Steuerung darauf verzichten, auf Modellereignisse zu hören und zu reagieren.		im Allgemeinen kann die Steuerung darauf verzichten, auf Modellereignisse zu hören und zu reagieren.
Zeile 194:		Zeile 194:
	darauf, wann der Benutzer welchen Teil der View betrachtet.		darauf, wann der Benutzer welchen Teil der View betrachtet.

	Der erste Kommunikationsvorgang ist relativ simpel. Der Benutzer aktiviert einen Controller (~~z.B.~~ per Tastenklick). Dies		Der erste Kommunikationsvorgang ist relativ simpel. Der Benutzer aktiviert einen Controller ({{zB}} per Tastenklick). Dies
	hat eine Modifikation des zugehörigen Modells zur Folge. Das Modell informiert die zugehörige View per Multicast. Die daraus		hat eine Modifikation des zugehörigen Modells zur Folge. Das Modell informiert die zugehörige View per Multicast. Die daraus
	resultierende Änderung der View wird irgendwann vom Benutzer wahrgenommen.		resultierende Änderung der View wird irgendwann vom Benutzer wahrgenommen.

	Der zweite Kommunikationsvorgang unterscheidet sich vom ersten dadurch, dass der Benutzer mit der View interagiert.		Der zweite Kommunikationsvorgang unterscheidet sich vom ersten dadurch, dass der Benutzer mit der View interagiert.
	Diese muss die Benutzeraktion (~~z.B.~~ Aktivierung eines Button per Mausklick) zunächst an einen Controller weiterleiten.		Diese muss die Benutzeraktion ({{zB}} Aktivierung eines Button per Mausklick) zunächst an einen Controller weiterleiten.
	Danach läuft der Kommunikationsprozess genauso wie zuvor ab.		Danach läuft der Kommunikationsprozess genauso wie zuvor ab.

Zeile 210:		Zeile 210:
	den Warenkorb und – sobald sich der Besteller eingeloggt hat – den zugehörigen Besitzer gespeichert: der Warenkatalog, eine aktuelle Auswahl des Warenkataloges,		den Warenkorb und – sobald sich der Besteller eingeloggt hat – den zugehörigen Besitzer gespeichert: der Warenkatalog, eine aktuelle Auswahl des Warenkataloges,
	der Inhalt des Warenkorbs, der Gesamtpreis der Waren im Warenkorb, die Anschrift des Bestellers etc.		der Inhalt des Warenkorbs, der Gesamtpreis der Waren im Warenkorb, die Anschrift des Bestellers etc.
	Die Modelldaten oder zumindest Teile davon (wie ~~z.B.~~ der gesamte Warenkatalog) werden häufig in einer Datenbank abgelegt (siehe auch [[Model-View-Controller-Service-Paradigma]]).		Die Modelldaten oder zumindest Teile davon (wie {{zB}} der gesamte Warenkatalog) werden häufig in einer Datenbank abgelegt (siehe auch [[Model-View-Controller-Service-Paradigma]]).

	Ein Darstellungsmodul visualisiert Modelldaten, wie ~~z.B.~~ die aktuelle Auswahl des Warenkataloges, mit Hilfe von Texten, Bildern und Videos.		Ein Darstellungsmodul visualisiert Modelldaten, wie {{zB}} die aktuelle Auswahl des Warenkataloges, mit Hilfe von Texten, Bildern und Videos.
	Der Benutzer kann die Auswahl der visualierten Elemente durch Filter oder Navigation abändern, er kann		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		Elemente des Kataloges in seinen Warenkorb legen und dort wieder entfernen etc. Für all diese Aktionen werden
Zeile 234:		Zeile 234:
	Auch der VCM-Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus mehreren VCM-Komponenten:		Auch der VCM-Prozess beschreibt das allgemeine Vorgehen häufig etwas ungenau. Viele Anwendungen bestehen aus mehreren VCM-Komponenten:
	Einer oder mehreren Kernanwendungen (Domain-Komponenten) sowie einer Rahmenanwendung (Frame-Komponente), die den Zugang zu und zwischen den Kernanwendungen steuert.		Einer oder mehreren 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.		In diesem Fall gibt es mehrere relativ unabhängige MVC-Prozesse. Die äußeren Komponenten (wie {{zB}} die Rahmenkomponente) können dabei mit den inneren Komponenten (wie {{zB}} die Kernkomponenten) kommunizieren.
	Der umgekehrte Weg sollte vermieden werden, damit Kernkomponenten problemlos in andere Umgebungen integriert werden können.		Der umgekehrte Weg sollte vermieden werden, damit Kernkomponenten problemlos in andere Umgebungen integriert werden können.

Zeile 269:		Zeile 269:
	beschreibt (siehe nachfolgendes Beispiel).		beschreibt (siehe nachfolgendes Beispiel).

	Bei einem CVM-Prozess läuft die Kommunikation {{iAllg}} synchron ab: Ein Client (wie ~~z.B.~~ ein Web-Browser)		Bei einem CVM-Prozess läuft die Kommunikation {{iAllg}} synchron ab: Ein Client (wie {{zB}} ein Web-Browser)
	übermittelt an einen Controller eine Anfrage (~~z.B.~~ in Form einer URL plus weiteren Daten) und wartet dann auf eine Antwort:		übermittelt an einen Controller eine Anfrage ({{zB}} in Form einer URL plus weiteren Daten) und wartet dann auf eine Antwort:
	eine View, die er dem Benutzer präsentieren kann.		eine View, die er dem Benutzer präsentieren kann.
	(Dies gilt sogar, wenn [[Ajax]] zu Einsatz kommt. Auch hier wartet der Client auf eine Anwort ohne allerdings den Browser zu blockieren.		(Dies gilt sogar, wenn [[Ajax]] zu Einsatz kommt. Auch hier wartet der Client auf eine Anwort ohne allerdings den Browser zu blockieren.
Zeile 361:		Zeile 361:

	* Die Anwendungslogik ist von den dazugehörenden Darstellungen und den Benutzerinteraktionen klar getrennt: [[Seapration of Concern]].		* Die Anwendungslogik ist von den dazugehörenden Darstellungen und den Benutzerinteraktionen klar getrennt: [[Seapration of Concern]].
	* Ein Modell kann durch viele Darstellungsmodule repräsentiert werden (~~z.B.~~ Detail-View und Übersichts-View wie ~~z.B.~~ eine Landkarte mit Akteuren, spielerspezifische Views bei Multiuser-Spielen, vierschiedene Ansichten eines 3D-Modells etc.).		* Ein Modell kann durch viele Darstellungsmodule repräsentiert werden ({{zB}} Detail-View und Übersichts-View wie {{zB}} eine Landkarte mit Akteuren, spielerspezifische Views bei Multiuser-Spielen, vierschiedene Ansichten eines 3D-Modells etc.).
	* Bei Multiuser-Spielen muss nur das Modell auf allen beteiligten Rechnenr synchronisiert werden. Eine realtive geringe Bandbreite reicht zur Übertragung aus.		* Bei Multiuser-Spielen muss nur das Modell auf allen beteiligten Rechnenr synchronisiert werden. Eine realtive geringe Bandbreite reicht zur Übertragung aus.
	* Bestehende Systeme können einfach erweitert werden, indem neue Module und MVC-Komponenten hinzugefügt werden.		* Bestehende Systeme können einfach erweitert werden, indem neue Module und MVC-Komponenten hinzugefügt werden.

← Nächstältere Version		Version vom 22. September 2017, 14:42 Uhr
Zeile 75:		Zeile 75:
	Ein Controllermodul kann direkt auf ein Modellmodul zugreifen, um die Inhalte zu manipulieren.		Ein Controllermodul kann direkt auf ein Modellmodul zugreifen, um die Inhalte zu manipulieren.

	Eine View kommuniziert ~~i. Allg.~~ direkt nur mit Controllermodulen, um diesen Benutzeraktionen, die über die View erfolgen, mitzuteilen.		Eine View kommuniziert {{iAllg}} direkt nur mit Controllermodulen, 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 Servicemodule sind nicht vorgesehen.		nicht alle relevanten Informationen enthalten. Zugriffe auf Servicemodule sind nicht vorgesehen.
Zeile 94:		Zeile 94:
	Die Controller-Module können direkt ({{zB}} via [[Unicast-Nachricht]]en) auf die View- und Modell-Module zugreifen		Die Controller-Module können direkt ({{zB}} via [[Unicast-Nachricht]]en) auf die View- und Modell-Module zugreifen
	und die View-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt		und die View-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt
	(~~i. Allg.~~ als Antworten auf Unicast-Nachrichten, evtl. auch mittels [[Callback]]-Routinen).		({{iAllg}} als Antworten auf Unicast-Nachrichten, evtl. auch mittels [[Callback]]-Routinen).

	Man beachte, dass in diesem Paradigma die Logik der Anwendung normalerweise im Controller und nicht im Modell realisiert wird		Man beachte, dass in diesem Paradigma die Logik der Anwendung normalerweise im Controller und nicht im Modell realisiert wird
Zeile 145:		Zeile 145:
	zur Manipulation der Spielfigur an das Modell weitergeleitet.		zur Manipulation der Spielfigur an das Modell weitergeleitet.

	Man beachte, dass das Modell ~~i. Allg.~~ aktiv ist, {{dh}} seinen Zustand selbstständig auch ohne Manipulatation durch die Steuerkomponete verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Modell selbst bewegt.		Man beachte, dass das Modell {{iAllg}} aktiv ist, {{dh}} seinen Zustand selbstständig auch ohne Manipulatation durch die Steuerkomponete verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Modell selbst bewegt.

	=== Erweiterung des MVC-Prozesses===		=== Erweiterung des MVC-Prozesses===
Zeile 183:		Zeile 183:

	Die direkte Kommunikation per Unicast-Nachrichten zwischen View und Controller, ziwchen View und Modell sowie zwischen Controller und Modell		Die direkte Kommunikation per Unicast-Nachrichten zwischen View und Controller, ziwchen View und Modell sowie zwischen Controller und Modell
	ist ~~i. Allg.~~ problemlos möglich, da in jedem Fall die Kommunikationspartner beim Initialisieren der Komponente eindeutig festliegen.		ist {{iAllg}} problemlos möglich, da in jedem Fall die Kommunikationspartner beim Initialisieren der Komponente eindeutig festliegen.
	Dies ist jedoch bei den Kommunikationspartnern der Modelle nicht der Fall: Die Anzahl der Views (und evtl. auch der Controller),		Dies ist jedoch bei den Kommunikationspartnern der Modelle nicht der Fall: Die Anzahl der Views (und evtl. auch der Controller),
	die nach einer Modelländerung aktualisiert werden müssen, liegt nicht von vorn herein fest und kann sich jederzeit ändern. Daher ist		die nach einer Modelländerung aktualisiert werden müssen, liegt nicht von vorn herein fest und kann sich jederzeit ändern. Daher ist
Zeile 269:		Zeile 269:
	beschreibt (siehe nachfolgendes Beispiel).		beschreibt (siehe nachfolgendes Beispiel).

	Bei einem CVM-Prozess läuft die Kommunikation ~~i. Allg.~~ synchron ab: Ein Client (wie z.B. ein Web-Browser)		Bei einem CVM-Prozess läuft die Kommunikation {{iAllg}} synchron ab: Ein Client (wie z.B. ein Web-Browser)
	übermittelt an einen Controller eine Anfrage (z.B. in Form einer URL plus weiteren Daten) und wartet dann auf eine Antwort:		übermittelt an einen Controller eine Anfrage (z.B. in Form einer URL plus weiteren Daten) und wartet dann auf eine Antwort:
	eine View, die er dem Benutzer präsentieren kann.		eine View, die er dem Benutzer präsentieren kann.

← Nächstältere Version		Version vom 22. September 2017, 14:41 Uhr
Zeile 14:		Zeile 14:
	Ein [[Model-View-Controller-Paradigma/Model\|MVC-Modell]] (engl. [[GlossaryWiki:Model-view-controller paradigma/Model\|MVC model]])		Ein [[Model-View-Controller-Paradigma/Model\|MVC-Modell]] (engl. [[GlossaryWiki:Model-view-controller paradigma/Model\|MVC model]])
	einer [[Model-View-Controller-Paradigma\|MVC]]-[[Anwendung]]		einer [[Model-View-Controller-Paradigma\|MVC]]-[[Anwendung]]
	dient zur Speicherung bestimmter Daten, ~~d.h.~~ zur Speicherung von Teilen des aktuellen Zustands der Anwendung.		dient zur Speicherung bestimmter Daten, {{dh}} zur Speicherung von Teilen des aktuellen Zustands der Anwendung.

	Ein MVC-Modell kann weitere Aufgaben übernehmen:		Ein MVC-Modell kann weitere Aufgaben übernehmen:
Zeile 35:		Zeile 35:
	===Controller (Steuerung)===		===Controller (Steuerung)===
	[[Model-View-Controller-Paradigma/Controller\|MVC-Controller]]		[[Model-View-Controller-Paradigma/Controller\|MVC-Controller]]
	(engl. [[GlossaryWiki:Model-view-controller paradigma/Controller\|MVC controllers]]) dienen zur Steuerung einer [[Model-View-Controller-Paradigma\|MVC]]-[[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 [[Model-View-Controller-Paradigma/Model\|Modell]] weiter.		(engl. [[GlossaryWiki:Model-view-controller paradigma/Controller\|MVC controllers]]) dienen zur Steuerung einer [[Model-View-Controller-Paradigma\|MVC]]-[[Anwendung]]. 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 ein [[Model-View-Controller-Paradigma/Model\|Modell]] weiter.

	Ein MVC-Controller kann weitere Aufgaben übernehmen:		Ein MVC-Controller kann weitere Aufgaben übernehmen:

	* Verarbeitung von Systemsignalen, wie ~~z.B.~~ einer Systemuhr (~~z.B.~~ „Spielzeit ist abgelaufen“)		* Verarbeitung von Systemsignalen, wie {{zB}} einer Systemuhr ({{zB}} „Spielzeit ist abgelaufen“)
	* Umsetzung der Komponentenlogik		* Umsetzung der Komponentenlogik
	* Kommunikation mit externen Datenquellen (zum Zweck der Datensynchronisation)		* Kommunikation mit externen Datenquellen (zum Zweck der Datensynchronisation)

	==Anmerkungen==		==Anmerkungen==
	Views könnten theoretisch auch Controller-Informationen (wie ~~z.B.~~ Fehler-Meldungen oder Service-Status-Meldungen) visualisieren.		Views könnten theoretisch auch Controller-Informationen (wie {{zB}} Fehler-Meldungen oder Service-Status-Meldungen) visualisieren.
	Allerdings würde dies dem Grundgedanken wiedersprechen, dass Views nur auf möglichst wenige andere Module zugreifen soll		Allerdings würde dies dem Grundgedanken wiedersprechen, dass Views nur auf möglichst wenige andere Module zugreifen soll
	(normalerweise greifen Views nur schreibend auf Controller zu).		(normalerweise greifen Views nur schreibend auf Controller zu).
Zeile 50:		Zeile 50:
	dann von einer View visualisiert werden.		dann von einer View visualisiert werden.

	Logische ''Sichten'' zu verwalten, wie ~~z.B.~~ die Regelung des Zugriffs auf verschiedene Daten abhängig von		Logische ''Sichten'' zu verwalten, wie {{zB}} die Regelung des Zugriffs auf verschiedene Daten abhängig von
	den Benutzerrechten, ist nicht die Aufgabe einer View, sondern		den Benutzerrechten, ist nicht die Aufgabe einer View, sondern
	Aufgabe eines Modells oder eines Controllers.		Aufgabe eines Modells oder eines Controllers.
Zeile 65:		Zeile 65:
	''View'', ''Controller'', ''Model''.		''View'', ''Controller'', ''Model''.

	Diese Architektur ist für interaktive Anwendungen wie ~~z.B.~~ Spiele sehr gut geeignet.		Diese Architektur ist für interaktive Anwendungen wie {{zB}} Spiele sehr gut geeignet.

	Die drei Module einer MVC-Komponente sind gemäß dem [[Schichtenparadigma]] in Ebenen angeordnet.		Die drei Module einer MVC-Komponente sind gemäß dem [[Schichtenparadigma]] in Ebenen angeordnet.
Zeile 71:		Zeile 71:

	Die unserste Ebene enthält das Modell. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit		Die unserste Ebene enthält das Modell. Das zugehörige Modul weiß nichts von den über ihr liegenden Module und kann mit diesen nur mit
	indirekt – ~~z.B.~~ durch Antworten auf [[Nachricht]]en oder mit Hilfe des [[Observer-Pattern]]s – kommunizieren.		indirekt – {{zB}} durch Antworten auf [[Nachricht]]en oder mit Hilfe des [[Observer-Pattern]]s – kommunizieren.

	Ein Controllermodul kann direkt auf ein Modellmodul zugreifen, um die Inhalte zu manipulieren.		Ein Controllermodul kann direkt auf ein Modellmodul zugreifen, um die Inhalte zu manipulieren.
Zeile 92:		Zeile 92:
	Diese Architektur ist für Web-Anwendungen sehr gut geeignet.		Diese Architektur ist für Web-Anwendungen sehr gut geeignet.

	Die Controller-Module können direkt (~~z.B.~~ via [[Unicast-Nachricht]]en) auf die View- und Modell-Module zugreifen		Die Controller-Module können direkt ({{zB}} via [[Unicast-Nachricht]]en) auf die View- und Modell-Module zugreifen
	und die View-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt		und die View-Module können direkt auf Modell-Module zugreifen. Alle anderen „Zugriffe“ erfolgen nur indirekt
	(i. Allg. als Antworten auf Unicast-Nachrichten, evtl. auch mittels [[Callback]]-Routinen).		(i. Allg. als Antworten auf Unicast-Nachrichten, evtl. auch mittels [[Callback]]-Routinen).
Zeile 100:		Zeile 100:

	====MVC-Multicast-Paradigma====		====MVC-Multicast-Paradigma====
	Ein MVC-Paradigma wird MVC-Multicast-Paradigma genannt, wenn alle Module nur indirekt, ~~d.h.~~ mit Hilfe		Ein MVC-Paradigma wird MVC-Multicast-Paradigma genannt, wenn alle Module nur indirekt, {{dh}} mit Hilfe
	von [[Multicast-Nachricht]]en kommunizieren.		von [[Multicast-Nachricht]]en kommunizieren.

Zeile 145:		Zeile 145:
	zur Manipulation der Spielfigur an das Modell weitergeleitet.		zur Manipulation der Spielfigur an das Modell weitergeleitet.

	Man beachte, dass das Modell i. Allg. aktiv ist, ~~d.h.~~ seinen Zustand selbstständig auch ohne Manipulatation durch die Steuerkomponete verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Modell selbst bewegt.		Man beachte, dass das Modell i. Allg. aktiv ist, {{dh}} seinen Zustand selbstständig auch ohne Manipulatation durch die Steuerkomponete verändern kann. Beispielsweise werden die gegnerischen Figuren, sofern es welche gibt, vom Modell selbst bewegt.

	=== Erweiterung des MVC-Prozesses===		=== Erweiterung des MVC-Prozesses===
Zeile 163:		Zeile 163:
	darüber informiert, dass sich etwas am Datenbestand des Modells geändert hat, dabei aber nicht mitteilt, welche		darüber informiert, dass sich etwas am Datenbestand des Modells geändert hat, dabei aber nicht mitteilt, welche
	Änderungen sich ergeben haben, müssen die Empfänger dieser Informations-Nachrichten gegebenenfalls beim		Änderungen sich ergeben haben, müssen die Empfänger dieser Informations-Nachrichten gegebenenfalls beim
	Sender der Nachricht „nachfragen“, ~~d.h.~~ auf bestimmte, für sie interessante Daten explizit zugreifen.		Sender der Nachricht „nachfragen“, {{dh}} auf bestimmte, für sie interessante Daten explizit zugreifen.

	Man beachte, dass Module immer auch mit gleichartigen Modulen kommunizieren können:		Man beachte, dass Module immer auch mit gleichartigen Modulen kommunizieren können:
Zeile 295:		Zeile 295:
	Sofern in einer Web-Anwendung die JSP-Seiten auch die Aufgaben des Controllers übernehmen, spricht man von einer '''Model-1-Architektur'''.<ref name="JSP 0.92"/><ref name="Best Practices"/>		Sofern in einer Web-Anwendung die JSP-Seiten auch die Aufgaben des Controllers übernehmen, spricht man von einer '''Model-1-Architektur'''.<ref name="JSP 0.92"/><ref name="Best Practices"/>

	Wenn in einem Web-Framework dagegen spezielle Servlets die Controller-Funktionalität übernehmen, ~~d.h.~~ die Views von dieser Funktionalität		Wenn in einem Web-Framework dagegen spezielle Servlets die Controller-Funktionalität übernehmen, {{dh}} die Views von dieser Funktionalität
	befreit werden, handelt es sich um eine CVM-Architektur, die im JSP-Umfeld allerdings '''Model-2-Architektur''' genannt wird.<ref name="JSP 0.92"/><ref name="Best Practices"/>		befreit werden, handelt es sich um eine CVM-Architektur, die im JSP-Umfeld allerdings '''Model-2-Architektur''' genannt wird.<ref name="JSP 0.92"/><ref name="Best Practices"/>

Zeile 338:		Zeile 338:
	Vom Benutzer abgesehen, der stets explizit mit dem System kommuniziert, erfolgt jede Kommunikation per [[Multicast-Nachricht]]:		Vom Benutzer abgesehen, der stets explizit mit dem System kommuniziert, erfolgt jede Kommunikation per [[Multicast-Nachricht]]:
	Ein Sender schickt Nachrichten aus an beliebig viele, dem Sender zu Beginn in der Regel noch unbekannte Empfänger.		Ein Sender schickt Nachrichten aus an beliebig viele, dem Sender zu Beginn in der Regel noch unbekannte Empfänger.
	Da die Empfänger nicht direkt (~~d.h.~~ per Unicast-Nachricht) beim Sender weitere Details erfragen können, müssen die		Da die Empfänger nicht direkt ({{dh}} per Unicast-Nachricht) beim Sender weitere Details erfragen können, müssen die
	Sender mit jeder wichtigen Nachricht alle notwendigen Detail-Informationen mitschicken.		Sender mit jeder wichtigen Nachricht alle notwendigen Detail-Informationen mitschicken.
	Dieser Nachteil wird jedoch durch den Vorteil aufgewogen, dass beliebige Module als Nachrichten-Empfänger definiert		Dieser Nachteil wird jedoch durch den Vorteil aufgewogen, dass beliebige Module als Nachrichten-Empfänger definiert