Model View Controller - Versionsgeschichte

Siegbert v2: Quellen und Weblinks überarbeitet (fast alle sind inzwischen offline => Archivlinks)

2024-09-22T21:03:54Z

Quellen und Weblinks überarbeitet (fast alle sind inzwischen offline => Archivlinks)

← Nächstältere Version		Version vom 22. September 2024, 23:03 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als Entwurfsmuster eingesetzt werden.<ref>{{~~cite~~ ~~web~~ \|url=~~http~~://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|~~title~~=Is MVC a design pattern or an architectural pattern? \| ~~author~~=~~Kamal~~ ~~Wickramanayake~~ \|~~date~~=2010-07-17 \|~~language~~=~~englisch \|work=Software View~~ \|~~accessdate~~=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als Entwurfsmuster eingesetzt werden.<ref>{{Internetquelle \|autor=Kamal Wickramanayake \|url=https://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|titel=Is MVC a design pattern or an architectural pattern? \|werk=Software View \|datum=2010-07-17 \|sprache=en \|abruf=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Zeile 130:		Zeile 130:

	== Literatur ==		== Literatur ==
	* Erich Gamma, Richard Helm, Ralph Johnson: ''Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software~~''.~~ 2~~. Auflage.~~ Addison-Wesley, ~~ISBN~~ 978-3-8273-1862-6.		* {{Literatur \|Autor=Erich Gamma, Richard Helm, Ralph Johnson \|Titel=Entwurfsmuster. Elemente wiederverwendbarer objektorientierter Software \|Auflage=2 \|Verlag=Addison-Wesley \|Sprache=de \|ISBN=978-3-8273-1862-6}}

	== Weblinks ==		== Weblinks ==
	* Steffen Düsel: [https://www.methodpark.de/blog/model-view-controller-mvc/ Model-View-Controller (MVC)] ~~(deutsch)~~		* {{Internetquelle \|autor=Steffen Düsel \|url=https://www.methodpark.de/blog/model-view-controller-mvc/ \|titel=Model-View-Controller (MVC) \|sprache=de \|archiv-url=https://web.archive.org/web/20210417082732/https://www.methodpark.de/blog/model-view-controller-mvc/ \|archiv-datum=2021-04-17 \|abruf=2021-06-17 \|abruf-verborgen=ja}}
	* [http://c2.com/cgi-bin/wiki?ModelViewController Portland Pattern Repository – ~~Model~~ ~~View~~ ~~Controller]~~ ~~(englisch)~~		* {{Internetquelle \|url=http://c2.com/cgi-bin/wiki?ModelViewController \|titel=Model View Controller \|werk=Portland Pattern Repository \|sprache=en \|archiv-url=https://web.archive.org/web/20160806075025/http://c2.com/cgi-bin/wiki?ModelViewController \|archiv-datum=2016-08-06 \|abruf=2007-12-04 \|abruf-verborgen=ja}}
	* Jeff Moore: [http://www.phpwact.org/pattern/model_view_controller Model View Controller] ~~(englisch)~~		* {{Internetquelle \|autor=Jeff Moore \|url=http://www.phpwact.org/pattern/model_view_controller \|titel=Model View Controller \|sprache=en \|archiv-url=https://web.archive.org/web/20160608102231/http://www.phpwact.org/pattern/model_view_controller \|archiv-datum=2016-06-08 \|abruf=2007-01-30 \|abruf-verborgen=ja}}
	* ~~[http~~://martinfowler.com/eaaDev/uiArchs.html ''GUI Architectures~~''.]~~ ~~Martin~~ ~~Fowler~~ ~~(englisch)~~		* {{Internetquelle \|autor=Martin Fowler \|url=https://martinfowler.com/eaaDev/uiArchs.html \|titel=GUI Architectures \|sprache=en \|abruf=2011-05-21 \|abruf-verborgen=ja}}

	== Einzelnachweise ==		== Einzelnachweise ==

Siegbert v2: Artikel verlinkt

2024-09-22T19:57:42Z

Artikel verlinkt

Änderungen zeigen

Aka: doppelten Link entfernt, typografische Anführungszeichen

2024-01-10T15:57:50Z

doppelten Link entfernt, typografische Anführungszeichen

← Nächstältere Version		Version vom 10. Januar 2024, 17:57 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als Entwurfsmuster eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Zeile 67:		Zeile 67:
	Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.		Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

	Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long Polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen ~~"das~~ ~~Beste"~~ vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.		Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long Polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen „das Beste“ vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.

	==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====		==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====

88.152.158.71 am 10. Januar 2024 um 11:52 Uhr

2024-01-10T11:52:14Z

← Nächstältere Version		Version vom 10. Januar 2024, 13:52 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[~~Muster#Beispiele\|Muster~~]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.

Sebastian.Dietrich: Änderungen von 80.156.183.73 (Diskussion) auf die letzte Version von Juergeen zurückgesetzt

2023-08-09T14:29:34Z

Änderungen von 80.156.183.73 (Diskussion) auf die letzte Version von Juergeen zurückgesetzt

← Nächstältere Version		Version vom 9. August 2023, 16:29 Uhr
Zeile 30:		Zeile 30:
	Die Begriffe des ursprünglichen MVC-Musters werden heute oft entlehnt, um Systeme begreiflich zu machen, die weitaus komplexer sind als die damalige Software. Dabei kommt es auf die Perspektive des betrachteten Teilsystems an, welche Elemente damit bezeichnet werden. So könnte ein Webbrowser als View eines größeren Gesamtsystems verstanden werden, während schon ein einzelnes Formularelement im Browser wiederum aus einem kleinen Datenmodell, der zugehörigen Darstellung und seiner Steuerung besteht. Die Grundidee der Trennung von Model, View und Controller hat sich erhalten, wird aber feiner granuliert und verschachtelt eingesetzt.		Die Begriffe des ursprünglichen MVC-Musters werden heute oft entlehnt, um Systeme begreiflich zu machen, die weitaus komplexer sind als die damalige Software. Dabei kommt es auf die Perspektive des betrachteten Teilsystems an, welche Elemente damit bezeichnet werden. So könnte ein Webbrowser als View eines größeren Gesamtsystems verstanden werden, während schon ein einzelnes Formularelement im Browser wiederum aus einem kleinen Datenmodell, der zugehörigen Darstellung und seiner Steuerung besteht. Die Grundidee der Trennung von Model, View und Controller hat sich erhalten, wird aber feiner granuliert und verschachtelt eingesetzt.

	Während sich viele Projekte als Model-View-Controller-Architektur definieren, wird der Begriff sehr vielfältig benutzt. Es etablieren sich neue Begriffe, wie das [[Model-View-Presenter]]-, das [[Model View ViewModel\|Model-View-ViewModel]]- oder das [[Model-View-Adapter]]-Muster, die versuchen, die Varianten präziser zu beschreiben~~. Auf Lock~~.		Während sich viele Projekte als Model-View-Controller-Architektur definieren, wird der Begriff sehr vielfältig benutzt. Es etablieren sich neue Begriffe, wie das [[Model-View-Presenter]]-, das [[Model View ViewModel\|Model-View-ViewModel]]- oder das [[Model-View-Adapter]]-Muster, die versuchen, die Varianten präziser zu beschreiben.

	=== Widget-Bibliotheken für Desktop-Applikationen ===		=== Widget-Bibliotheken für Desktop-Applikationen ===

80.156.183.73: /* Nicht festgelegte Funktionalitäten */

2023-08-09T09:47:58Z

Nicht festgelegte Funktionalitäten

← Nächstältere Version		Version vom 9. August 2023, 11:47 Uhr
Zeile 30:		Zeile 30:
	Die Begriffe des ursprünglichen MVC-Musters werden heute oft entlehnt, um Systeme begreiflich zu machen, die weitaus komplexer sind als die damalige Software. Dabei kommt es auf die Perspektive des betrachteten Teilsystems an, welche Elemente damit bezeichnet werden. So könnte ein Webbrowser als View eines größeren Gesamtsystems verstanden werden, während schon ein einzelnes Formularelement im Browser wiederum aus einem kleinen Datenmodell, der zugehörigen Darstellung und seiner Steuerung besteht. Die Grundidee der Trennung von Model, View und Controller hat sich erhalten, wird aber feiner granuliert und verschachtelt eingesetzt.		Die Begriffe des ursprünglichen MVC-Musters werden heute oft entlehnt, um Systeme begreiflich zu machen, die weitaus komplexer sind als die damalige Software. Dabei kommt es auf die Perspektive des betrachteten Teilsystems an, welche Elemente damit bezeichnet werden. So könnte ein Webbrowser als View eines größeren Gesamtsystems verstanden werden, während schon ein einzelnes Formularelement im Browser wiederum aus einem kleinen Datenmodell, der zugehörigen Darstellung und seiner Steuerung besteht. Die Grundidee der Trennung von Model, View und Controller hat sich erhalten, wird aber feiner granuliert und verschachtelt eingesetzt.

	Während sich viele Projekte als Model-View-Controller-Architektur definieren, wird der Begriff sehr vielfältig benutzt. Es etablieren sich neue Begriffe, wie das [[Model-View-Presenter]]-, das [[Model View ViewModel\|Model-View-ViewModel]]- oder das [[Model-View-Adapter]]-Muster, die versuchen, die Varianten präziser zu beschreiben.		Während sich viele Projekte als Model-View-Controller-Architektur definieren, wird der Begriff sehr vielfältig benutzt. Es etablieren sich neue Begriffe, wie das [[Model-View-Presenter]]-, das [[Model View ViewModel\|Model-View-ViewModel]]- oder das [[Model-View-Adapter]]-Muster, die versuchen, die Varianten präziser zu beschreiben. Auf Lock.

	=== Widget-Bibliotheken für Desktop-Applikationen ===		=== Widget-Bibliotheken für Desktop-Applikationen ===

Juergeen: Grossschreibung gemaess RR § 55 (3) - siehe WP:Auskunft#Gross-/Kleinschreibung englischer Begriffe im Deutschen

2023-04-14T23:11:45Z

Grossschreibung gemaess RR § 55 (3) - siehe WP:Auskunft#Gross-/Kleinschreibung englischer Begriffe im Deutschen

← Nächstältere Version		Version vom 15. April 2023, 01:11 Uhr
Zeile 67:		Zeile 67:
	Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.		Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

	Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long ~~polling~~]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.		Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long Polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.

	==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====		==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====

Schotterebene: Formatierung

2023-04-08T15:27:52Z

Formatierung

← Nächstältere Version		Version vom 8. April 2023, 17:27 Uhr
Zeile 67:		Zeile 67:
	Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.		Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

	Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[~~long~~ polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.		Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.

	==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====		==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====

217.61.195.200: Link

2023-04-08T14:54:51Z

Link

← Nächstältere Version		Version vom 8. April 2023, 16:54 Uhr
Zeile 67:		Zeile 67:
	Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.		Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

	Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[~~Long-Polling~~]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.		Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[long polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen "das Beste" vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.

	==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====		==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====

2A02:8108:5940:1314:E98B:1B20:9FC5:3731: Änderung der Übersetzung von "view" von "Präsentation" auf die richtigere "Ansicht", um Verwirrung insb. bezüglich des MVP-Musters zu vermeiden

2023-04-07T18:28:03Z

Änderung der Übersetzung von "view" von "Präsentation" auf die richtigere "Ansicht", um Verwirrung insb. bezüglich des MVP-Musters zu vermeiden

← Nächstältere Version		Version vom 10. Januar 2024, 17:57 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als Entwurfsmuster eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Zeile 67:		Zeile 67:
	Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.		Bei klassischen Webanwendungen kann der Browser nicht nach dem klassischen [[Beobachter (Entwurfsmuster)\|Observer-Muster]] unmittelbar auf Änderungen des Models auf dem Server reagieren. Jede Antwort (HTTP-Response) an den Browser setzt eine Anfrage (HTTP-Request) voraus. Man spricht vom Request-Response-Cycle. Daraus folgt, dass das Observer-Muster auch auf Seiten des Servers seine Vorteile nicht ausspielen kann. Weil es somit einen Mehraufwand bedeutet hätte, kam es typischerweise nicht zum Einsatz. Stattdessen tritt meist der Controller als aktiver Vermittler zwischen Model und View im Rahmen eines Request-Response-Cycles auf.

	Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long Polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen ~~"das~~ ~~Beste"~~ vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.		Neuere [[Webanwendung]]en erlauben bereits die Implementierung eines Observer-Musters. Die hierbei verwendete [[Push-Medien\|Push-Technologie]] (Server-Push) erlaubt dem Server, Ereignisse direkt und ohne Anfrage an die Clients zu übermitteln. Viele Implementierungen nutzen hierbei das sogenannte [[Long Polling]] (Request mit verzögerter Antwort, bis ein Ereignis eintritt) oder die neueren [[WebSocket\|Websockets]]. Einige [[JavaScript-Framework]]s abstrahieren hierbei das Push-Verfahren und nutzen „das Beste“ vom jeweiligen Browser bzw. der Serveranwendung zur Verfügung gestellte Verfahren. Somit ist es auch möglich, das Observer-Muster in Webanwendungen einzuführen.

	==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====		==== Die besonderen Herausforderungen des Hyperlinks und der Form-Action ====

← Nächstältere Version		Version vom 10. Januar 2024, 13:52 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[~~Muster#Beispiele\|Muster~~]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Entwurfsmuster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.

← Nächstältere Version		Version vom 7. April 2023, 20:28 Uhr
Zeile 1:		Zeile 1:
	[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]		[[Datei:ModelViewControllerDiagram2.svg\|mini\|Ein Model-View-Controller-Konzept. Eine durchgezogene Linie symbolisiert hier eine direkte [[Assoziation (UML)\|Assoziation]], eine gestrichelte eine indirekte Assoziation (zum Beispiel über einen [[Beobachter (Entwurfsmuster)\|Beobachter]]).]]

	'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-~~Präsentation~~-Steuerung'') ist ein [[Muster#Beispiele\|Muster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''~~Präsentation~~'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.		'''{{lang\|en\|Model View Controller}}''' ('''MVC''', {{enS}} für ''Modell-Ansicht-Steuerung'') ist ein [[Muster#Beispiele\|Muster]] zur Unterteilung einer [[Software]] in die drei Komponenten ''Datenmodell'' (englisch ''{{lang\|en\|model}}''), ''Ansicht'' (englisch ''{{lang\|en\|view}}'') und ''Programmsteuerung'' (englisch ''{{lang\|en\|controller}}''). Das Muster kann sowohl als [[Architekturmuster]] als auch als [[Entwurfsmuster]] eingesetzt werden.<ref>{{cite web \|url=http://www.swview.org/blog/mvc-design-pattern-or-architectural-pattern \|title=Is MVC a design pattern or an architectural pattern? \| author=Kamal Wickramanayake \|date=2010-07-17 \|language=englisch \|work=Software View \|accessdate=2016-12-16}}</ref> Ziel des Musters ist ein flexibler Programmentwurf, der eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dann zum Beispiel möglich, eine Anwendung zu schreiben, die dasselbe Modell nutzt und es dann für Windows, Mac, Linux oder für das Internet zugänglich macht. Die Umsetzungen nutzen dasselbe Modell, nur Controller und View müssen dabei jeweils neu implementiert werden.

	Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.		Das MVC-Konzept wurde 1979 zunächst für Benutzeroberflächen in [[Smalltalk (Programmiersprache)\|Smalltalk]] durch [[Trygve Reenskaug]] beschrieben (Seeheim-Modell), der damals an Smalltalk im [[Xerox PARC]] arbeitete. Es gilt mittlerweile aber als De-facto-Standard für den Grobentwurf vieler komplexer Softwaresysteme, teils mit Differenzierungen und oftmals mehreren jeweils nach dem MVC-Muster aufgeteilten Modulen.
Zeile 9:		Zeile 9:

	=== Modell ''({{lang\|en\|model}})'' ===		=== Modell ''({{lang\|en\|model}})'' ===
	Das Modell enthält Daten, die von der ~~Präsentation~~ dargestellt werden. Es ist von ~~Präsentation~~ und Steuerung unabhängig. Die Änderungen der Daten werden der ~~Präsentation~~ durch das [[Beobachter (Entwurfsmuster)\|Entwurfsmuster „Beobachter“]] bekanntgegeben. In manchen Umsetzungen des MVC-Musters enthält das Modell eine [[Geschäftslogik]], die für die Änderung der Daten zuständig ist.		Das Modell enthält Daten, die von der Ansicht dargestellt werden. Es ist von Ansicht und Steuerung unabhängig. Die Änderungen der Daten werden der Ansicht durch das [[Beobachter (Entwurfsmuster)\|Entwurfsmuster „Beobachter“]] bekanntgegeben. In manchen Umsetzungen des MVC-Musters enthält das Modell eine [[Geschäftslogik]], die für die Änderung der Daten zuständig ist.

	=== ~~Präsentation~~ ''({{lang\|en\|view}})'' ===		=== Ansicht ''({{lang\|en\|view}})'' ===
	Die ~~Präsentation~~ ist für die Darstellung der Daten des Modells und die Realisierung der Benutzerinteraktionen zuständig. Sie kennt das Modell, dessen Daten sie präsentiert, ist aber nicht für die Verarbeitung dieser Daten zuständig. Des Weiteren ist sie von der Steuerung unabhängig. Die Bekanntgabe von Benutzerinteraktionen an die Steuerung geschieht nach dem Entwurfsmuster „Beobachter“. Die ~~Präsentation~~ wird über Änderungen der Daten im Modell mithilfe des Entwurfsmuster „Beobachter“ unterrichtet und kann daraufhin die Darstellung aktualisieren. Die ~~Präsentation~~ verwendet oft das [[Kompositum (Entwurfsmuster)\|Entwurfsmuster „Kompositum“]].		Die Ansicht ist für die Darstellung der Daten des Modells und die Realisierung der Benutzerinteraktionen zuständig. Sie kennt das Modell, dessen Daten sie präsentiert, ist aber nicht für die Verarbeitung dieser Daten zuständig. Des Weiteren ist sie von der Steuerung unabhängig. Die Bekanntgabe von Benutzerinteraktionen an die Steuerung geschieht nach dem Entwurfsmuster „Beobachter“. Die Ansicht wird über Änderungen der Daten im Modell mithilfe des Entwurfsmuster „Beobachter“ unterrichtet und kann daraufhin die Darstellung aktualisieren. Die Ansicht verwendet oft das [[Kompositum (Entwurfsmuster)\|Entwurfsmuster „Kompositum“]].

	=== Steuerung ''({{lang\|en\|controller}})'' ===		=== Steuerung ''({{lang\|en\|controller}})'' ===
	Die Steuerung verwaltet die ~~Präsentation~~ und das Modell. Sie wird von der ~~Präsentation~~ über Benutzerinteraktionen (mithilfe des [[Beobachter (Entwurfsmuster)\|Entwurfsmusters „Beobachter“]]) informiert, wertet diese aus und nimmt daraufhin Anpassungen an der ~~Präsentation~~ sowie Änderungen an den Daten im Modell vor. In einigen modernen Implementierungen des MVC-Musters aktualisiert die Steuerung die Daten im Modell nicht mehr direkt, stattdessen aktualisiert sie die Daten indirekt, indem sie auf die im Modell implementierte Geschäftslogik zugreift. In einem Spezialfall des MVC-Musters kann die Steuerung auch mehrere ~~Präsentationen~~ oder mehrere Modelle gleichzeitig verwalten.		Die Steuerung verwaltet die Ansicht und das Modell. Sie wird von der Ansicht über Benutzerinteraktionen (mithilfe des [[Beobachter (Entwurfsmuster)\|Entwurfsmusters „Beobachter“]]) informiert, wertet diese aus und nimmt daraufhin Anpassungen an der Ansicht sowie Änderungen an den Daten im Modell vor. In einigen modernen Implementierungen des MVC-Musters aktualisiert die Steuerung die Daten im Modell nicht mehr direkt, stattdessen aktualisiert sie die Daten indirekt, indem sie auf die im Modell implementierte Geschäftslogik zugreift. In einem Spezialfall des MVC-Musters kann die Steuerung auch mehrere Ansichten oder mehrere Modelle gleichzeitig verwalten.

	=== Nicht festgelegte Funktionalitäten ===		=== Nicht festgelegte Funktionalitäten ===
Zeile 33:		Zeile 33:

	=== Widget-Bibliotheken für Desktop-Applikationen ===		=== Widget-Bibliotheken für Desktop-Applikationen ===
	Als [[Widget]]s werden die einzelnen Komponenten grafischer Oberflächen bezeichnet, wie Menüpunkte oder Editor-Komponenten. Widgets zeichnen sich dadurch aus, dass sie neben der ~~Präsentation~~ auch typische Merkmale des klassischen Controllers in einer Komponente vereinen, wie das Event-Handling. Einige Widgets, wie z. B. Auswahllisten, können sogar über ein eigenes internes Modell verfügen, wobei dieses dann mit dem eigentlichen Modell synchronisiert werden muss.		Als [[Widget]]s werden die einzelnen Komponenten grafischer Oberflächen bezeichnet, wie Menüpunkte oder Editor-Komponenten. Widgets zeichnen sich dadurch aus, dass sie neben der Ansicht auch typische Merkmale des klassischen Controllers in einer Komponente vereinen, wie das Event-Handling. Einige Widgets, wie z. B. Auswahllisten, können sogar über ein eigenes internes Modell verfügen, wobei dieses dann mit dem eigentlichen Modell synchronisiert werden muss.

	Obwohl die Widgets die feste Dreiteilung durchbrechen, spricht man trotzdem noch von einer Model-View-Controller-Architektur. Es kommen auch Komponenten wie Filter zur Sortierung oder Bestätigungsdialoge vor, die sich nicht eindeutig in die klassische Dreiteilung einordnen lassen.		Obwohl die Widgets die feste Dreiteilung durchbrechen, spricht man trotzdem noch von einer Model-View-Controller-Architektur. Es kommen auch Komponenten wie Filter zur Sortierung oder Bestätigungsdialoge vor, die sich nicht eindeutig in die klassische Dreiteilung einordnen lassen.
Zeile 42:		Zeile 42:

	Das MVC-Entwurfsmuster definiert auch den Rahmen für die Entwickler von GUI-Frameworks. Ein fertiges GUI-Framework beinhaltet:		Das MVC-Entwurfsmuster definiert auch den Rahmen für die Entwickler von GUI-Frameworks. Ein fertiges GUI-Framework beinhaltet:
	# eine ~~Präsentation~~ ''({{lang\|en\|view}})'' in Form ausimplementierter [[Steuerelement\|GUI-Widgets]],		# eine Ansicht ''({{lang\|en\|view}})'' in Form ausimplementierter [[Steuerelement\|GUI-Widgets]],
	# die Vereinbarung eines zugrundeliegenden Datenmodells in Form von Schnittstellen,		# die Vereinbarung eines zugrundeliegenden Datenmodells in Form von Schnittstellen,
	# die Vereinbarung von [[Ereignis (Programmierung)\|Ereignissen]] (englisch ''events'') auf Grund von Benutzerinteraktionen in Form von Schnittstellen und ausimplementierten Klassen sowie		# die Vereinbarung von [[Ereignis (Programmierung)\|Ereignissen]] (englisch ''events'') auf Grund von Benutzerinteraktionen in Form von Schnittstellen und ausimplementierten Klassen sowie