Model-View-Controller-Service-Paradigma - Versionsgeschichte

Kowa am 22. September 2017 um 14:39 Uhr

2017-09-22T14:39:35Z

Kowa am 22. September 2017 um 14:30 Uhr

2017-09-22T14:30:18Z

← Nächstältere Version		Version vom 22. September 2017, 14:30 Uhr
Zeile 199:		Zeile 199:
	==Quellen==		==Quellen==
	<references/>		<references/>
	<ol start="2">		<ol start="4">
	<li>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</li>		<li>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</li>
	</ol>		</ol>

Kowa am 22. September 2017 um 14:29 Uhr

2017-09-22T14:29:37Z

Änderungen zeigen

Kowa am 5. März 2014 um 16:44 Uhr

2014-03-05T16:44:48Z

← Nächstältere Version		Version vom 5. März 2014, 16:44 Uhr
Zeile 1:		Zeile 1:
	{{MVC:Menü}}		{{MVC:Menü}}
	=Definition=		=Definition=
	[[~~Medium~~:MVCS-Module 01.png\|gerahmt\|\|rechts\|MVCS-Module]]		[[Datei:MVCS-Module 01.png\|gerahmt\|\|rechts\|MVCS-Module]]
	Als [[Model-View-Controller-Service-Paradigma]]		Als [[Model-View-Controller-Service-Paradigma]]
	(engl. [[GlossaryWiki:Model-view-controller-service paradigm\|Model-view-controller-service paradigm]]) oder		(engl. [[GlossaryWiki:Model-view-controller-service paradigm\|Model-view-controller-service paradigm]]) oder
Zeile 54:		Zeile 54:
	==MVCS-Paradigma: Varianten (Definitionen nach [[Kowarschick (MMProg)]])==		==MVCS-Paradigma: Varianten (Definitionen nach [[Kowarschick (MMProg)]])==

	[[~~Medium~~:VCSM-Schichtenarchitektur 01.png \| gerahmt \| rechts \| Besipiel für eine VCSM-Schichtenarchitektur]]		[[Datei:VCSM-Schichtenarchitektur 01.png \| gerahmt \| rechts \| Besipiel für eine VCSM-Schichtenarchitektur]]
	===VCSM-Paradigma===		===VCSM-Paradigma===
	Ein MVCS-Paradigma wird '''VCSM-Paradigma''' genannt, wenn die vier zugehörigen Module folgende Schichtenarchitektur bilden:		Ein MVCS-Paradigma wird '''VCSM-Paradigma''' genannt, wenn die vier zugehörigen Module folgende Schichtenarchitektur bilden:
Zeile 81:		Zeile 81:
	Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controllermodulen.		Der Benutzer stellt das „oberste Modul“ dar. Er kommuniziert nur mit View- und Controllermodulen.

	[[~~Medium~~:CVMS-Schichtenarchitektur 01.png \| gerahmt \| rechts \| Besipiel für eine CVMS-Schichtenarchitektur]]		[[Datei:CVMS-Schichtenarchitektur 01.png \| gerahmt \| rechts \| Besipiel für eine CVMS-Schichtenarchitektur]]

	===CVMS-Paradigma===		===CVMS-Paradigma===
Zeile 114:		Zeile 114:

	= Der MVCS-Prozess =		= Der MVCS-Prozess =
	[[~~Medium~~:MVCS-Prozess 01.png\|gerahmt\|rechts\|Der MVCS-Prozess]]		[[Datei:MVCS-Prozess 01.png\|gerahmt\|rechts\|Der MVCS-Prozess]]
	Das MVCS-Paradigma erweitert das [[Model-View-Controller-Paradigma\|MVC-Paradigma]] um die so genannte Servicemodule. 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. Die Aufgabe der Präsentationsmodule (Views) ändert sich nicht.		Das MVCS-Paradigma erweitert das [[Model-View-Controller-Paradigma\|MVC-Paradigma]] um die so genannte Servicemodule. 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. Die Aufgabe der Präsentationsmodule (Views) ändert sich nicht.

Zeile 142:		Zeile 142:

	=CVMS-Prozess, Model 2=		=CVMS-Prozess, Model 2=
	[[~~Medium~~:CVMS-Prozess 01.png\|gerahmt\|rechts\|CVMS-Prozess]]		[[Datei:CVMS-Prozess 01.png\|gerahmt\|rechts\|CVMS-Prozess]]

	Den meisten „Web Application Frameworks“ liegt heutzutage ein MVC-Paradigma zugrunde (vgl. [[Model-View-Controller-Paradigma/Umsetzungen\|MVC-Paradigma/Umsetzungen]]).		Den meisten „Web Application Frameworks“ liegt heutzutage ein MVC-Paradigma zugrunde (vgl. [[Model-View-Controller-Paradigma/Umsetzungen\|MVC-Paradigma/Umsetzungen]]).
Zeile 185:		Zeile 185:
	In diesem Fall gibt es mehrere relativ unabhängige MVCS-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 MVCS-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.		Der umgekehrte Weg sollte vermieden werden, damit Kernkomponenten problemlos in andere Umgebungen integriert werden können.
	[[~~Medium~~:MVCS-Prozess 02.png\|gerahmt\|links\|MVCS-Prozess 2 (mit Trennung in äußere und innere MVCS-Komponenten)]]		[[Datei:MVCS-Prozess 02.png\|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).		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).

Kowa: /* CVMS-Prozess, Model 2 */

2012-11-20T16:07:08Z

CVMS-Prozess, Model 2

← Nächstältere Version		Version vom 20. November 2012, 16:07 Uhr
Zeile 155:		Zeile 155:
	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, bis die Anwort eingetroffen ist.		(Dies gilt sogar, wenn [[Ajax]] zu Einsatz kommt. Auch hier wartet der Client, bis die Anwort eingetroffen ist.
	Die als Ergebnis gelieferte Teilview wird dann vom Client verwendet, um die aktuell dem Benutzer präsentierte View zu aktualisieren.)		Die als Ergebnis vom Server gelieferte Teilview wird dann vom Client verwendet, um die aktuell dem Benutzer präsentierte clientseitige View zu aktualisieren.)

	Um eine Antwort generieren zu können, leitet der Controller die erhaltenen Daten an ein Modell weiter (2.).		Um eine Antwort generieren zu können, leitet der Controller die erhaltenen Daten an ein Modell weiter (2.).

Rayza: /* Beispiel Warenkorb */

2012-11-20T07:38:03Z

Beispiel Warenkorb

← Nächstältere Version		Version vom 20. November 2012, 07:38 Uhr
Zeile 130:		Zeile 130:
	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
	dem Benutzer in der View spezielle Eingabefelder ([Checkbox]]es, [[Drop-Down-Menü]]s, [[Textfeld]]er, [[Link]]s etc.) präsentiert.		dem Benutzer in der View spezielle Eingabefelder ([[Checkbox]]es, [[Drop-Down-Menü]]s, [[Textfeld]]er, [[Link]]s etc.) präsentiert.
	Jedes mal, wenn der Benutzer eine dieser Felder mit Hilfe der Maus oder der Tastatur bedient, leitet das		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.		Darstellungsmodul eine entsprechende Nachricht an das zuständige Steuermodul weiter.

Kowa: /* Siehe auch */

2011-09-14T11:06:14Z

Siehe auch

← Nächstältere Version		Version vom 14. September 2011, 11:06 Uhr
Zeile 204:		Zeile 204:

	=Siehe auch=		=Siehe auch=
	*{{Vgl\|~~odel~~-View-Controller-Paradigma}}		*{{Vgl\|Model-View-Controller-Paradigma}}
	*{{Vgl\|Logic-Data-View-Controller-Service-Paradigma]]<noinclude>[[Kategorie:Objektorientierte Programmierung}}		*{{Vgl\|Logic-Data-View-Controller-Service-Paradigma}}<noinclude>[[Kategorie:Objektorientierte Programmierung]]
	[[Kategorie:Glossar]][[Kategorie:MVC]]		[[Kategorie:Glossar]][[Kategorie:MVC]]
	[[en:MVCS]]		[[en:MVCS]]
	[[Kategorie:Kapitel:Multimedia-Programmierung]]		[[Kategorie:Kapitel:Multimedia-Programmierung]]
	</noinclude>		</noinclude>

Kowa: /* Siehe auch */

2011-09-14T11:05:51Z

Siehe auch

← Nächstältere Version		Version vom 14. September 2011, 11:05 Uhr
Zeile 204:		Zeile 204:

	=Siehe auch=		=Siehe auch=
	*~~[[Model~~-View-Controller-Paradigma]]		*{{Vgl\|odel-View-Controller-Paradigma}}
	*[[Logic-Data-View-Controller-Service-Paradigma]]<noinclude>[[Kategorie:Objektorientierte Programmierung]]		*{{Vgl\|Logic-Data-View-Controller-Service-Paradigma]]<noinclude>[[Kategorie:Objektorientierte Programmierung}}
	[[Kategorie:Glossar]][[Kategorie:MVC]]		[[Kategorie:Glossar]][[Kategorie:MVC]]
	[[en:MVCS]]		[[en:MVCS]]
	[[Kategorie:Kapitel:Multimedia-Programmierung]]		[[Kategorie:Kapitel:Multimedia-Programmierung]]
	</noinclude>		</noinclude>

Kowa am 12. September 2011 um 09:40 Uhr

2011-09-12T09:40:21Z

← Nächstältere Version		Version vom 12. September 2011, 09:40 Uhr
Zeile 199:		Zeile 199:
	=Quellen=		=Quellen=
	<ol>		<ol>
	<li>[[Quelle::Berkovitz, Joe (2006): An architectural blueprint for Flex applications]]</li>		<li>{{Quelle\|Berkovitz, Joe (2006): An architectural blueprint for Flex applications}}</li>
	<li>[[Quelle::Kowarschick, W.: Multimedia-Programmierung]]</li>		<li>{{Quelle\|Kowarschick, W.: Multimedia-Programmierung}}</li>
	</ol>		</ol>

Kowa: /* Quellen */

2011-09-05T11:22:19Z

Quellen

← Nächstältere Version		Version vom 5. September 2011, 11:22 Uhr
Zeile 198:		Zeile 198:

	=Quellen=		=Quellen=
			<ol>
	*[[Quelle::Berkovitz, Joe (2006): An architectural blueprint for Flex applications]]		<li>[[Quelle::Berkovitz, Joe (2006): An architectural blueprint for Flex applications]]</li>
	*[[Quelle::Kowarschick, W.: Multimedia-Programmierung]]		<li>[[Quelle::Kowarschick, W.: Multimedia-Programmierung]]</li>
			</ol>

	=Siehe auch=		=Siehe auch=

← Nächstältere Version		Version vom 22. September 2017, 14:39 Uhr
Zeile 14:		Zeile 14:
	Ein [[Model-View-Controller-Service-Paradigma/Model\|MVCS-Modell]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/model\|MVCS model]])		Ein [[Model-View-Controller-Service-Paradigma/Model\|MVCS-Modell]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/model\|MVCS model]])
	einer [[Model-View-Controller-Service-Paradigma\|MVCS]]-[[Anwendung]]		einer [[Model-View-Controller-Service-Paradigma\|MVCS]]-[[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 MVCS-Modell kann weitere Aufgaben übernehmen:		Ein MVCS-Modell kann weitere Aufgaben übernehmen:
Zeile 34:		Zeile 34:
	===Controller (Steuerung)===		===Controller (Steuerung)===
	[[Model-View-Controller-Service-Paradigma/Controller\|MVCS-Controller]]		[[Model-View-Controller-Service-Paradigma/Controller\|MVCS-Controller]]
	(engl. [[GlossaryWiki:Model-view-controller-service paradigma/controller\|MVCS controllers]]) dienen zur Steuerung einer [[Model-View-Controller-Service-Paradigma\|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		(engl. [[GlossaryWiki:Model-view-controller-service paradigma/controller\|MVCS controllers]]) dienen zur Steuerung einer [[Model-View-Controller-Service-Paradigma\|MVCS]]-[[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
	[[Model-View-Controller-Service-Paradigma/Model\|Modelle]] und/oder [[Model-View-Controller-Service-Paradigma/Service\|Servicemodule]] weiter.		[[Model-View-Controller-Service-Paradigma/Model\|Modelle]] und/oder [[Model-View-Controller-Service-Paradigma/Service\|Servicemodule]] weiter.

	Ein MVCS-Controller kann weitere Aufgaben übernehmen:		Ein MVCS-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

Zeile 45:		Zeile 45:
	Ein [[Model-View-Controller-Service-Paradigma/Service\|Service]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/service\|service]])		Ein [[Model-View-Controller-Service-Paradigma/Service\|Service]] (engl. [[GlossaryWiki:Model-view-controller-service paradigm/service\|service]])
	dient einer [[Model-View-Controller-Service-Paradigma\|MVCS]]-[[Anwendung]] zur Kommunikation		dient einer [[Model-View-Controller-Service-Paradigma\|MVCS]]-[[Anwendung]] zur Kommunikation
	mit der Außenwelt, ~~d.h.~~ mit Dienste-Anbietern wie [[Web-Server]]n, [[Datenbanksystem]]en oder auch [[Dateisystem]]en.		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 [[Model-View-Controller-Service-Paradigma/Model\|Modell]]en auslesen und in externe		Die Kommunikation kann in beide Richtungen erfolgen: Services können sowohl Daten aus [[Model-View-Controller-Service-Paradigma/Model\|Modell]]en auslesen und in externe
	[[Repository\|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Modelle einfügen.		[[Repository\|Repositories]] schreiben, als auch Daten aus externen Repositories lesen und in Modelle einfügen.
Zeile 63:		Zeile 63:

	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 Servicemodul kennt nur die darunterliegende Modelle und kann nur auf diese zugreifen		Ein Servicemodul kennt nur die darunterliegende Modelle und kann nur auf diese zugreifen
	(sowie ~~i. Allg.~~ auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).		(sowie {{iAllg}} auf externe Datenquellen, sofern es nicht nur Filterfunktionen wahrnimmt).

	Ein Controllermodul kann entweder direkt auf ein Modellmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel		Ein Controllermodul kann entweder direkt auf ein Modellmodul zugreifen oder indirekt mit Hilfe eines Servicemoduls (zum Beispiel
Zeile 75:		Zeile 75:
	da die Modelle keinen direkten Zugriff auf andere Module haben.		da die Modelle keinen direkten Zugriff auf andere Module haben.

	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 88:		Zeile 88:
	''Controller'', ''View'', ''Model'' und ''Service''.		''Controller'', ''View'', ''Model'' und ''Service''.

	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,
	die View-Module können direkt auf Modell-Module zugreifen und die Modell-Module können direkt mit Service-Modulen kommunizieren,		die View-Module können direkt auf Modell-Module zugreifen und die Modell-Module können direkt mit Service-Modulen kommunizieren,
	um Daten mit externen Repositories auszutauschen. Alle anderen „Zugriffe“ erfolgen nur indirekt		um Daten mit externen Repositories auszutauschen. 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 in den Controllern und nicht in den Modellen realisiert werden sollte,		Man beachte, dass in diesem Paradigma die Logik der Anwendung in den Controllern und nicht in den Modellen realisiert werden sollte,
Zeile 97:		Zeile 97:

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

Zeile 149:		Zeile 149:
	das so genannte [[Model 2]] eingeführt, welches eine CVMS-Architektur beschreibt.		das so genannte [[Model 2]] eingeführt, welches eine CVMS-Architektur beschreibt.

	Bei einem CVMS-Prozess läuft die Kommunikation ~~i. Allg.~~ synchron ab (siehe Abbildung „CVMS-Prozess“):		Bei einem CVMS-Prozess läuft die Kommunikation {{iAllg}} synchron ab (siehe Abbildung „CVMS-Prozess“):

	Ein Client (wie ~~z.B.~~ ein Web-Browser) übermittelt an einen Controller eine Anfrage (1.)		Ein Client (wie {{zB}} ein Web-Browser) übermittelt an einen Controller eine Anfrage (1.)
	– ~~z.B.~~ in Form einer URL plus weiteren Daten – und wartet dann auf eine Antwort (11.):		– {{zB}} in Form einer URL plus weiteren Daten – und wartet dann auf eine Antwort (11.):
	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, bis die Anwort eingetroffen ist.		(Dies gilt sogar, wenn [[Ajax]] zu Einsatz kommt. Auch hier wartet der Client, bis die Anwort eingetroffen ist.
Zeile 159:		Zeile 159:
	Um eine Antwort generieren zu können, leitet der Controller die erhaltenen Daten an ein Modell weiter (2.).		Um eine Antwort generieren zu können, leitet der Controller die erhaltenen Daten an ein Modell weiter (2.).
	Das Modell enthält dabei nicht nur typische [[Session]]-Daten – wie Session-ID, Benutzer-Daten, Warenkorb-Inhalt etc. –, sondern auch		Das Modell enthält dabei nicht nur typische [[Session]]-Daten – wie Session-ID, Benutzer-Daten, Warenkorb-Inhalt etc. –, sondern auch
	Informationen, die dem Benutzer präsentiert werden sollen – wie ~~z.B.~~ bestimmte Waren, für die sich		Informationen, die dem Benutzer präsentiert werden sollen – wie {{zB}} bestimmte Waren, für die sich
	der Benutzer aktuell interessiert. Das Modell kann mit Hilfe von Service-Modulen Daten aus externen Datenbeständen		der Benutzer aktuell interessiert. Das Modell kann mit Hilfe von Service-Modulen Daten aus externen Datenbeständen
	(Datenbanken, Web-Services, XML-Repositories etc.) nachladen oder auch Informationen dorthin übertragen (3., 4. und 5.).		(Datenbanken, Web-Services, XML-Repositories etc.) nachladen oder auch Informationen dorthin übertragen (3., 4. und 5.).
Zeile 183:		Zeile 183:
	Viele Anwendungen bestehen aus mehreren MVCS-Komponenten:		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.		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 MVCS-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 MVCS-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.
	[[Datei:MVCS-Prozess 02.png\|gerahmt\|links\|MVCS-Prozess 2 (mit Trennung in äußere und innere MVCS-Komponenten)]]		[[Datei:MVCS-Prozess 02.png\|gerahmt\|links\|MVCS-Prozess 2 (mit Trennung in äußere und innere MVCS-Komponenten)]]