Diskussion:Model View Controller/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Model View Controller/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung auVorlage:SSerhalb der Wikipedia

https://de.wikiup.org/wiki/Diskussion:Model_View_Controller/Archiv/1#Thema_1

HMVC könnte man auch mal nebenbei erwähnen

oder verlinken.

genau - drum WP:Sei mutig --Sebastian.Dietrich ✉ 23:51, 30. Okt. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  13:25, 13. Feb. 2021 (CET)

Artikel irreführend und fehlerhaft

Dieser Artikel ist eher verwirrend und irreführend als hilfreich.

Einige Beispiele:

- Die Geschichte des MVC Paradigmas kommt zu kurz. Stattdessen wird das Thema nur auf Web-Applikationen begrenzt

- Ein MVC Model 2 ist mir bisher nirgendwo anders unter gekommen. Es gibt eine JSP Model 1 und JSP Model 2-Architektur, wobei das JSP Model 2 dem MVC-Pattern entspricht (siehe http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html Kap. 4.4.1.0.1). Ist das hier gemeint?

- Die Verarbeitung der Daten geschieht im Model und nicht im Controller (http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html Kap. 11.1.1)

- Das Beispiel samt Bildern ist unsinnig, da das JSP Model 2 (MVC für Web-Applikationen) ja genau festlegt, dass JSPs den Views entsprechen und Servlets die Rolle der Controller übernehmen. Im Beispiel gibt es nur JSPs, also ist es eine JSP Model 1-Architektur und die ist eben genau nicht nach dem MVC-Muster entworfen.

- Wie schon in anderen Kommentaren erwähnt, ist das Beispiel auf eine Web-Applikation beschränkt. Der Ursprung des MVC-Models liegt aber in klassischen dialogorientierten Applikationen. Wie steht's mit dem MVC-Entwurfsmuster in anderen Programmiersprachen? In diesem Artikel geht's irgendwie nur um Java/J2EE.

- Wenn man über MVC in Zusammenhang mit J2EE schreibt, muss man auch etwas über EJB und Application Server sagen. Hierüber wird ja z.B. das Model abgebildet. Das Model kann dann von unterschiedlichen View-Controller-Paaren verwendet werden (z.B. Rich Clients oder eben Web-Applikationen) usw.

Wenn hier jemand mehr über den Ursprung und die allgemeinere Bedeutung des MVC-Paradigmas schreiben könnte, würde ich mich bereit erklären, die spezielle Bedeutung für Web-Applikationen zu übernehmen. Den Artikel aber nur auf Web-Applikationen zu reduzieren finde ich nicht ok.

--MiSter

Also ich bin nicht gerade ein J2EE Experte. Aber nach meinen Heuristiken ist der Artikel nicht soo schlecht.

1. Die Geschichte eines Modells ist sicher erwaehnenswert, aber wenn sie nicht da ist, ist ein Artikel auch nicht automatisch schlecht.
2. Ich wuerde Modell und Verarbeitung soweit es geht trennen. Es gibt viele Wege Daten zu verarbeiten und man sollte sich den Weg offen halten diesen zu aendern, ohne das Model anzufassen (pers. Meinung).
3. Ich habe nicht den Eindruck, dass der Artikel hier auf Web Entwicklung beschraenkt ist. Der Author hat es nur als Beispiel genannt. Nur MVC2 hat er explizit in die Web Applikationsecke gestellt.
4. Ein Architektur Modell sollte unabhaengig von der Sprache sein und das ist der Artikel in weiten Teilen.
5. J2EE ist als eine Implementierungmoeglichkeit erwaehnenswert, aber nicht zwingend Notwendig. Da ja ein Datenmodell nicht von einer Implementierung abhaengt.

Wie gesagt, ich bin kein Experte fuer das Thema und eine Erweiterung des Artikels um Deine Meinung wird sicher nicht schaden. Ein bischen was ist an Deiner Ansicht sicherlich dran, aber Deine Kritik ist schon arg Negativ.

Gruss -- Sparti 2. Jul 2005 23:09 (CEST)

1. Das Model muss die Daten _nicht_ persistent halten. Es kann dafür sorgen das die Daten aus einer DB oder einem File geladen werden. Die Model Informationen können sich jedoch auch aus bestimmten Systeminformationen ableiten.

--Tobi kn 21:40, 30. Jul 2005 (CEST)

Bei Gelegenheit sollte auch folgender Punkt überarbeitet werden: Einerseits heißt es "Das Model kennt weder die View noch den Controller, ..." und andererseits liest man "Die View kennt das Model und ist dort registriert ..." und "... so sendet das Model einen Event, der dazu führt, dass sich beide grafischen Controls parallel aktualisieren". Wenn man nicht schon genau weiß, wie das MVC tatsächlich funktioniert, verwirren diese Aussagen, denn sie scheinen im Widerspruch zu stehen. Setzt die Benachrichtigung doch auch Kenntnis voraus, oder?

Gruss -- Volodia 21:30, 21. Dez 2005 (CEST)

• Das ist wohl wieder mal eine unzulässige Vermischung und Verwechslung von dem MVC Paradigma und dem Observer Pattern. Passiert sogar Professoren an der Uni, sowas ... Hcii 10:34, 17. Mär 2006 (CET)

---

Ich bin auch der Ansicht, dass der Artikel die Rollen von Model und Controller falsch beschreibt. Der Artikel in der englischen Wikipedia leider auch.

Möglicher Grund für diese Verwirrung ist die häufige Verwendung des Begriffs Controller im Zusammenhang mit dem Entwurfsmuster Entity-Control-Boundary (vgl. AgileWiki:EntityControlBoundary).

In Smalltalk-80 MVC enthält das Modell nicht nur die Daten sondern auch die Programmlogik: "Finally, the model manages the behavior and data of the application domain [...]".

Eine sehr ausführliche Übersicht über GUI-Architekturen gibt Martin Fowler. Er schreibt u. A.: "Probably the widest quoted pattern in UI development is Model View Controller (MVC) - it's also the most misquoted. I've lost count of the times I've seen something described as MVC which turned out to be nothing like it."

Noch ein Wort zu MVC in Smalltalk: Das Muster wird in einigen Dialekten nicht mehr in der ursprünglichen Form angewendet: Pollok hat keine Controller und Dolphin hat MVP.

MVC verwendet das Beobachter-Muster zur Kommunikation vom Model zur Benutzerschnittstelle, bestehend aus View und Controller. Viele Frameworks setzen stattdessen einen Vermittler (Mediator) zwischen View und Model ein. Prominentes Beispiel ist das JFace Data-Binding. Viele Missverständnisse ließen sich vermeiden, wenn man den den Vermittler nicht Controller nennt (Beispiel).

-- Sascha Dördelmann

Ich habe soeben den Artikel generalüberholt, da ich mich zur Zeit sehr intensiv mit MVC auseinandersetze und von dem wikipedia-Artikel gelinde gesagt entsetzt war. Viele unwichtige und nebensächliche Dinge habe ich herausgeworfen und die musterorientierte Sicht auf MVC beschrieben. Ich glaube zwar nicht dass MVC ein 'echtes' Muster ist, habe diesen Begriff jedoch trotzdem überall eingefügt um den Artikel zu vereinheitlichen.

Man könnte überlegen, ob der Begriff 'Präsentation' glücklich gewählt ist, und ob es wirklich notwendig ist MVC zu Übersetzen. Wie heisst es so schön in 'Entwurfsmuster von Kopf bis Fuß': Es gibt zu viele, zu schlechte Übersetzungen. Ich denke auch dass Model 2 einen eigenen Artikel verdient hat.

Es ist ausserdem falsch, dass MVC irgendetwas vereinfacht! Die meisten Muster fügen Komplexität hinzu, und MVC enthält mindestens drei verschiedene Entwurfsmuster. Jede Modell-Klasse wird durch das Beobachtermuster komplexer. Jede View-Klasse wird durch die Anzahl an benötigten Komponenten unübersichtlich. Und bei richtiger Implementierung des Controllers wird auch dieser komplexer, aufgrund des Strategiemusters. MVC vereinfacht nichts, sondern vereinheitlicht. Das ist der riesige Vorteil. Dies kann dann durchaus dazu führen, dass Modell und View/Controller vollkommen unabhängig voneinander entwickelt werden können, unter der Vorraussetzung, dass die Schnittstelle des Modells bekannt ist. --85.179.217.254 12:16, 4. Dez. 2007 (CET)

Ich finde die Übersetzung Präsentation für View verwirrend, da es auch ein mit MVC verwandtes Muster MVP (Model View Presenter) gibt. Vielleicht sollte man View besser mit Sicht oder Ansicht übersetzen, um keine Verwirrung zu stiften. -- O. Jacot-Descombes

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  13:25, 13. Feb. 2021 (CET)

Verschiedene Inhalte in verschiedenen Sprachen

Anlaesslich dieses unbefriedigenden Artikels moechte ich einen Vorschlag machen, wie man eine weitverbreitete, aber unnoetige Ineffizienz des globalen Wikipedia-Systems beheben koennte: Beispielsweise ist das Thema "Model-View-Controller" fundamental wichtig in der gesamten Software-Industrie und natuerlich nicht laender- oder sprachspezifisch. Es gibt aber einen relativ grossen Unterschied in Inhalt und Reifegrad zwischen dem, was das englische Wikipedia zum Thema sagt, und dem, was das deutsche dazu sagt. Wer beides liest, und nicht selbst Experte ist, kann nur den Kopf schuetteln.... Waere es da nicht sinnvoller, wenn jemand den eindeutig reiferen englischen Artikel-Stand in das Deutsche uebersetzen wuerde --- als deutsche Anfangsversion des Artikels sozusagen. Muesste sowas bei sprach-neutralen Themen nicht eigentlich Wikipedia-weit von den Supervisoren angeregt und organisiert werden ? --Eltope 20:40:32, 5. Aug 2005 (CEST)

Ich denke das ist im Prinzip eine gute Idee und wird auch immer mal wieder gemcht. Eine Art Supervison widerspricht aber dem Wikiprinzip und ich persoenlich denke, dass eben gerade die Unabhaengigkeit der deutschen Wikipedia auch pontential fuer Kreatitivaet hat. Einfaches Abkupfern wuerde die Vielartigkeit verhindern. Also lieber abwarten und nach und nach aus den Sprachen die besten Teile zusammenfuehren. Das sollte auch keine Einbahnstrasse sein, denn es gibt auch in der Deutschen Wikipedia Artikel, die den amerikanischen Gegenstuecken weit ueberlegen sind. Gruss -- sparti 15:41, 4. Aug 2005 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  13:25, 13. Feb. 2021 (CET)

Rollenverteilung

Ich habe folgenden Text aus dem Artikel entfernt:

Gleichzeitig bringt die Trennung auch eine Rollenverteilung mit sich. Fachkräfte können so optimal, ihrer Fähigkeit entsprechend, eingesetzt werden:

• Controller - Der Programmierer implementiert das Softwaredesign. In der Prozess- und Automatisierungstechnik um die Abbildung der Prozess- und Verfahrenstechnik, in der Wirtschaftswelt handelt es sich um die Abbildung von Geschäftsprozessen.
• die durch den Prozess die nötige Geschäftslogik (implementiert Algorithmen, stellt fertig aufbereitete Daten bereit, etc.)
• View - Ein Gestalter oder GUI-Designer erstellt das grafische Erscheinungsbild
• Model - Datenbankexperten kümmern sich um die optimale Datenverwaltung, Datenbankdesign usw.

Grund: Die Trennung der Aufgaben in dieser Weise ist nicht möglich. Alle drei Komponenten (Model, View und Controller) gehören zum Softwaredesign und müssen von einem Architekten designed und von einem Programmierer implementiert werden. Weder kann die View nur von einem Grafiker o.Ä. entwickelt werden, noch ist ein DB-Spezialist der richtige Mann (oder Frau) für den Entwurf der Models: die Models sind Teil eines Objektmodells, dass die Daten abbildet, was aber nicht unbedingt 1:1 auf die Datenbank übertragen werden kann (wenn man von relationalen Datenbanken ausgeht, was wohl in denallermeisten Fällen der Fall sein dürfte).

Ein GUI-Designer und ein DB-Spezialist sind zwar meistens nötig oder sinnvoll, aber ihre Aufgaben werden von MVC wenig berührt. -- Semper 20:45, 23. Okt. 2006 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  13:25, 13. Feb. 2021 (CET)

Komponenten

Das Modell kennt weder die Präsentation noch die Steuerung[...]

Das steht da so - trotzdem zeigt das Bild darüber Pfeile vom Model zum View und zum Controller. Das ist doch grundfalsch, oder? Das Model ruft View und/oder Controller doch nie direkt auf, es sei denn man verwendet das Observer-Pattern - doch das gehört doch eigentlich nicht in die Grafik, wie ich finde.

Im Übrigen empfinde ich die Seite auch als etwas web-lastig, besonders das mit MVC2 ist mir unklar. Wenn damit nur das Model2 gemeint ist - MVC2 sagt dazu doch keiner, oder?

--Florian Sening 13:28, 31. Jul. 2007 (CEST)

Das Bild wurde leider entfernt. Aber: Das Modell an sich sagt absolut nichts über die Beziehungen der "Komponenten" aus, sondern ausschließlich über die Rollenverteilung. Wie die Komponenten/Rollen zusammenarbeiten ist letztendlich gar nicht vorgegeben. Das (alte) Bild sollte genau das veranschaulichen, nämlich, dass alle Richtungen/Beziehungen möglich sind. Wie weiter oben schonmal geschrieben: MVC ist eine Vereinheitlichung! Das Observer-Patter hat damit herzlich wenig zu tun: Es ist ausschließlich EINE Realisierung - und nicht allgemeingültig. Es ist ja durchaus denkbar, dass das Modell den konkreten Controller kennt (wozu auch immer) - im übrigen kann auch das Observer-Pattern durchaus als eine solche Beziehung ansehen. Unter dem Aspekt ist übrigens das jetzige Bild (ganz oben) auch "nur" eine Ausprägung.

--Karsten Meier 18. Mar 2008

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Überarbeiten

Der Artikel ist meiner Einschätzung nach zu großen Teilen falsch und sollte komplett überarbeitet werden.

Zum Beispiel: "Das MVC-Architekturmuster trifft keine Aussage über die Positionierung der Geschäftslogik innerhalb der MVC-Klassen. Diese kann je nach Anwendungsfall besser im Control-Modul aufgehoben sein oder besser in das Modell verlagert werden (z.B. wenn es mehrere Control-Module gibt)." Das ist kompletter Humbug. Geschäftslogik hat nichts mit MVC zu tun, da MVC *NUR* für die Präsentationsschicht zuständig ist. Quelle: http://www.galileocomputing.de/openbook/oo/oo_06_moduleundarchitektur_001.htm

Falsch: "Der Begriff Modell-Präsentation-Steuerung (MPS) bzw. englisch Model-View-Controller (MVC) bezeichnet ein Architekturmuster zur Aufteilung von Softwaresystemen in die drei Einheiten: Datenmodell (engl. Model), Präsentation (engl. View) und Programmsteuerung (engl. Controller)." Richtig: "MVC ist kein Schichtenmodell" Quelle: http://www.galileocomputing.de/openbook/oo/oo_06_moduleundarchitektur_001.htm Gruß Jan

Aufteilung in drei Einheiten und "MVC ist kein Schichtenmodell" wiedersprechen sich nicht. Konkret ist es so, dass im 3-Schichtenmodell Controller und View in der obersten Schicht (Präsentationsschicht) sind und sich das Modell in der mittleren Schicht befindet. Über die Datenhaltungsschicht macht MVC keine Aussage. Dass MVC nur für die Präsentation zuständig ist, stimmt nicht. Das M in MVC bezieht sich eindeutig auf das zugrundeliegende Datenmodell. --85.179.217.254 11:45, 4. Dez. 2007 (CET)

Zitat: "Geschäftslogik hat nichts mit MVC zu tun, da MVC *NUR* für die Präsentationsschicht zuständig ist." Was für ein Blödsinn. Das ist definitiv falsch. --91.33.204.176 00:30, 7. Jan. 2008 (CET)

Ich würde mich freuen, wenn meine Vorredner ihre Aussagen ("eindeutig" bzw. "Blödsinn") durch Quellen o.ä. belegen könnten und nicht einfach nur als Behauptung aufstellen würden. Gruß Jan

Bin kein Vorredner, aber: Schau mal einfach in eine der Quellen - vor allem die im Artikel verlinkten Notizen des Autors dieses Begriffs. Der sollte es ja wissen. MVC ist nämlich weder in einer "Präsentationsschicht" angesiedelt, noch ist das Model als Datenmodell zu übersetzen. Letzteres ergibt in einem objektorientierten Kontext auch keinen Sinn, da es keine Trennung zwischen Daten und Logik gibt. Die Galileo Autoren beziehen sich zwar laufend auf jene Smalltalk-Quellen, schreiben aber bizarrerweise, dass ein Modell "zunächst überhaupt nichts mit der Logik in der Domäne zu tun" habe. Das ist besonders lustig, da in den genannten Quellen exakt das Gegenteil steht. Beispiel: "Finally, the model manages the behavior and data of the application domain, ". Quelle: Steve Burbeck: Applications Programming in Smalltalk-80: How to use Model-View-Controller (MVC). Noch ein Zitat daraus: "To use the MVC paradigm effectively you must understand the division of labor within the MVC triad." Das gelingt anscheinend den Wenigsten. 217.226.55.80 (19:25, 7. Jan. 2011 (CET), Datum/Uhrzeit nachträglich eingefügt, siehe Hilfe:Signatur)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Komponenten Interaktion

Die Grafik ist irreführend und stellt einer der wesentlichen Bestandteile des MVC Konzepts falsch dar: Im Idealfall hat die View überhaupt nichts mit dem Model zu tun. Dass dies leider oft unzulänglich in der Praxis umgesetzt wird steht bei der dem Konzept zu Grunde liegenden Idee keine Rolle. Eine Grafik sollte daher eher hierarchisch und wie folgt aufgebaut sein:

View <---> Controller <---> Model

In Kästchen und übereinander und hübsch...wie auch immer. Aber zwischen View und Model sollte keine Verbindung sein.

das stimmt nicht. der view liest bei MVC sehr wohl aus dem model und kennt es auch. er schreibt allerdings (was in dem bild imho falsch ist) nicht hinein, das ist dem controller vorbehalten. deine kleine skizze beschreibt einen teil von Presentation-Abstraction-Control -- ∂ 12:59, 12. Nov. 2007 (CET)

Der gestrichelte Pfeil gibt den Weg der Daten an. Er bedeutet also: View benutzt Modell und erhält von diesem Daten. Eine Erklärung zu diesem Bild wäre natürlich angebracht. --85.179.217.254 11:43, 4. Dez. 2007 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Geschäftslogik?!

Das Modell enthält die darzustellenden Daten und ggf. (abhängig von der Implementation des MVC-Patterns) auch die Geschäftslogik.

Geschäftslogik? Was ist denn Geschäftslogik? --Abdull 16:30, 3. Feb. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Wozu das ganze?

Was mir hier völlig fehlt, ist eine Erklärung (auch für Nicht-Experten), wozu das ganze eigentlich gut sein soll. Welche Vorteile hat man durch die Anwendung von MVC? Gibt es auch Nachteile?--84.73.34.245 20:24, 20. Apr. 2008 (CEST)

Das steht im zweiten Satz des Artikels: Ziel des Musters ist ein flexibles Programmdesign, das u.a. eine spätere Änderung oder Erweiterung erleichtern und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglichen soll.

Um das richtig zu verstehen, muss man das wohl mindestens einmal selbst durchexerzieren und als Voraussetzung die Vorteile der modularen Programmierung kennen.

Tipp: Module, Klassen, Verträge - Ein Lehrbuch zur komponentenorientierten Softwarekonstruktion mit Component Pascal Bautsch 21:04, 20. Apr. 2008 (CEST)

Leider ist das nicht mehr als schöne Theorie. Ob man nun mit MVS oder Item-basiert arbeitet, ist für die Flexibilität von Code vollkommen irrelevant. Modulare Programmierung ist schön und gut. Hat aber erstmal nicht direkt was mit MVC zu tun. --217.231.127.157 22:49, 6. Aug. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Entwurfsmuster

Die drei "Entwurfsmuster"-Sätze am Ende der Abschnitte "Model", "View", "Controller" sind -- im besten Falle -- unklar, aber meines Erachtens falsch. Imwiefern "entspricht" zum Beispiel die View dem Entwurfsmuster "Kompositum". Das hat doch überhaupt nichts miteinander zu tun. Ich kann das Entwurfsmuster "Kompositum" verwenden, ohne mich um MVC zu scheren, und ich kann MVC ohne das Entwurfsmuster erreichen. Analog die beiden anderen Fälle. --Dalgliesh 08:51, 10. Mai 2008 (CEST)

Das war ich, mit den Entwurfsmustern, und etlichen anderen Änderungen, die den Artikel erst sinnvoll gemacht haben. Es geht hier nicht darum, dass das eine auch ohne das andere existiert. Das steht ausser Frage. Aber wenn man sich näher mit Entwurfsmustern beschäftigt, dann kann man feststellen, dass MVC genau diese Muster verwendet. Wer z.B. das Beobachtermuster kennt und verstanden hat, wird viel weniger Probleme mit MVC haben, eben weil es ganz offenstichtlich dieses verwendet, um Änderungen zu publizieren. Eigentlich is mir das zu doof, das zu erklären, weil es zu trivial ist. Das ganze als falsch zu bezeichnen kratzt an meinem Ego und lässt mich an deiner Kompetenz in diesem Punkt zweifeln. --78.51.73.214 21:17, 5. Jul. 2008 (CEST)

So, ich habe jetzt die Formulierung etwas abgeändert, um zu verdeutlichen was gemeint ist. Ich hoffe das kommt Dir ein wenig entgegen. Brauchte erst mal ein paar Wochen um mich von dieser Kritik zu erholen ;) --217.227.220.230 14:43, 24. Jul. 2008 (CEST)

Die ursprüngliche Kritik ist m.E. völlig berechtigt. Das MVC das Observer Pattern nutzt steht ausser Frage (Reenskaug geht soweit zu sagen, dass MVC für die meisten Entwickler nichts anderes ist, als verschiedene Observer auf eine bestimmte Art und Weise zusammengesteckt. (http://www.artima.com/articles/dci_vision.html)). Das es sich bei Views allerdings um eine per Composition-Pattern rekursiv aufgebaute Teil-Ganze Beziehung handeln muss ist falsch. Es ist möglich, den View so zu bauen, aber keinesfalls notwendig. Nicht alles, was Präsentation und Datenmodell trennt ist gleich MVC und nicht alle Muster, die man neben MVC dafür verwenden kann sind Teil von MVC. Ich empfehle dazu den Artikel über GUI Architekturen von Martin Fowler (http://martinfowler.com/eaaDev/uiArchs.html) oder das C2 Wiki (http://c2.com/cgi/wiki?ModelViewController). Du solltest dein Ego etwas robuster aufbauen und dich nicht gleich von inhaltlicher Kritik an deinen Artikelergänzungen angegriffen fühlen. Solange diese Kritik sachlich bleibt, ist sie in diesem Ramen mE völlig richtig am Platz. Persönliche Anfeindungen (... lässt mich an deiner Kompetenz ... zweifeln, ...) gehören hier jedoch nicht hin. -- Vvs 10:44, 26. Mär. 2009 (CET)

<ego rugged/> ;) Hmm, sicherlich haste recht, was meine harsche Äußerung angeht. Verzeihung Dangliesh. Nun gut, man könnte die View auch anders realisieren, aber ist es dann noch MVC? Hmmm, vielleicht sollte man es umformulieren, so dass dort steht: 'Meistens wird Views als blablubb...'. Die anderen Sachen, welche du erwähntest sind mir durchaus bekannt und bewusst, und wurden (dachte ich) durch meine Änderungen auch deutlich gemacht. --78.51.134.231 10:03, 14. Apr. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Benutzungsoberfläche?

Im 2. Absatz der Einleitung - Ist das Absicht? Oder ist die Benutzeroberfläche gemeint? -- Grottenolm 23:54, 16. Okt. 2009 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

ASP.net MVC

... sollte man vielleicht hineinnehmen, wenn schon so viel über web-spezifisches mvc geschrieben wird! http://www.asp.net/%28S%28d35rmemuuono1wvm1gsp2n45%29%29/mvc/ --80.121.152.250 09:13, 22. Feb. 2010 (CET)

Naja - Web MVC Frameworks gibt es wie Sand am Meer (ein Großteil der Liste von Webframeworks sind MVC Web-Frameworks) - ASP.net MVC ist nicht wirklich eine Besonderheit. --Sebastian.Dietrich 19:33, 22. Feb. 2010 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Das Ding heißt "drei Schichten Modell"

Das Ding heißt "drei Schichten Modell". Oder könnt ihr schon eure eigene Muttersprache nicht mehr sprechen? (nicht signierter Beitrag von 93.186.202.3 (Diskussion) 17:39, 14. Sep. 2011 (CEST))

Nein, das ist etwas anderes. "Drei-Schichten-Modell" (wenn du schon Wert auf korrektes Deutsch legst, dann bitte mit Durchkopplung) ist etwas anderes als MVC. Beides sind Architekturmuster. Aber während das Drei-Schichten-Modell eine inhaltliche Trennung vorsieht, geht es bei MVC um eine technische Trennung. Man kann durchaus MVC ohne Drei-Schichten-Architektur haben und umgekehrt. --Der Hâkawâti ✉ 09:43, 17. Sep. 2011 (CEST)

Genau. Siehe auch Schichtenarchitektur --Sebastian.Dietrich ✉ 10:15, 17. Sep. 2011 (CEST)

Aber wenigstens Viertelgeviertstrich sollten eingefügt werden, also "Model View Controller" nach "Model-View-Controller" verschoben werden. Bei der Übernahme von Fremdwörtern sollten diesen nach den Regeln der deutschen Rechtschreibung erfolgen. Siehe Leerzeichen in Komposita#Abweichungen aus Unkenntnis. In den meisten verlinkten Artikel wird sowieso die Bindestrichschreibweise verwendet. --Boshomi 14:25, 12. Nov. 2011 (CET)

Gerne :-) Und wie schauts bei Domain-Driven Design aus? --Sebastian.Dietrich ✉ 16:27, 12. Nov. 2011 (CET)

hm. Das ist eine harte Nuss: engl "domain-driven design". Da man Deutsch sowieso die Zusammenschreibung ermöglicht könnte man dort wo im Englischen ein Bindestrich verwendet wird auf all Fälle geprüft werden, ob beim Import ins Deutsche eine Zusammenschreibung auf alle Fälle bevorzugen. => "Domaindriven-Design" wenn man es als Hauptwort haben will, oder "domaindriven Design" wenn man das Adjektiv importiert. Ich würde in diesem Fall eher die zweite Variante bevorzugen. Wenn keine dieser Varianten gefällt, könnte auch nach einen passenden deutschen Begriff gefahndet werden. --Boshomi 20:02, 12. Nov. 2011 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Controller und Strategie

Verwendet der Controller tatsächlich ein Strategie Muster, oder ist das nicht eher ein Kommando Muster? Schließlich können am Modell ganz unterschiedliche Arbeiten vorgenommen werden und es sind nicht die gleichen Arbeiten nach einem anderen Algorithmus. -- Parvulus (Diskussion) 22:30, 5. Apr. 2012 (CEST)

Ich sehe hier weder ne Strategie, noch ein Kommando. Beiden Mustern ist gemein, dass konkrete Implementierungen zur Laufzeit austauschbar sind (==> Abstrakte Kopplung). Aber hast du nen austauschbaren Controller? Wohl eher nicht. Außerdem definieren sich Patterns nicht allein durch ihre Struktur, sondern auch durch das Problem das sie lösen und die zugrunde gelegte Metapher/Denkweise. Bei ner Strategy hast du nen austauschbaren Algorithmus. Der muss nicht das selbe Ergebnis liefern (und tut das oft auch nicht). Aber man kann jeweils ne konkrete Aufgabe benennen. Bei nem Command ist der Aufrufer tendenziell eher nicht der Kontext (bei der Strategy hingegen schon). Kommandos sind quasi externalisierte Methoden. Hier sehe ich weder einen veränderlichen Algorithmus, noch eine externalisierten Methode. Sowohl Struktur, als auch Semantik sprechen m.E. gegen Strategie und Kommando. Ich bin dafür, den Verweis zu streichen. Der Verweis auf den Observer ist hingegen unstrittig. --Der Hâkawâti ✉ 20:54, 9. Apr. 2012 (CEST)

ack, weder strategy pattern noch commmand pattern passen hier. hab's mal rausgeworfen [1] -- ∂ 21:33, 9. Apr. 2012 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

HTML5

Unter "Heutige Umsetzungen" steht unter "Verzicht auf Verzicht auf das Observer-Muster, dass ein Model-Observer nicht möglich sei, jedoch würde ich mal vermuten, dass eine Umsetzung mit Websockets so etwas durchaus erlaubt (s. Dropbox Weboberfläche). (nicht signierter Beitrag von 109.90.237.78 (Diskussion) 21:02, 20. Feb. 2014 (CET))

Der Bereich "Heutige Umsetzungen" ist allgemein sehr dürftig. --Eatthis86 (Diskussion) 11:52, 10. Jan. 2016 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Was nicht passt, wird passend gemacht

Ich verstehe nicht, warum hier auf Gedeih und Verderb das Web als Beispiel herhalten muss.

MVC beschreibt, wie man Klassen INNERHALB eines (objekt-orientierten) Software-Projekts entwerfen soll(te). Im Wesentlichen, dass man UI und Datenlogik nicht vermischen soll. UI-Klassen sollen keine Geschäftslogik enthalten, die Geschäftslogik soll die UI nicht (direkt) steuern. Das ist letztlich nichts anderes als Datenkapselung + Single Responsibility Prinzip.

Webbrowser, HTTP-Server und Datenbank sind aber nicht verschiedene Komponenten eines Software-Projekts, sondern es sind verschiedene Software-Projekte (die oft genug überhaupt nichts mit objekt-orientierung zu tun haben). Wenn sich eine IT-Architektur über verschiedene Programme erstreckt (die nicht per Anspringen von Methoden, sondern per Datenaustausch über Sockets, Pipes etc. miteinander kommunizieren) ist es völliger Quatsch eine Trennung zu "fordern". Die KÖNNEN fast nicht anders als getrennt zu sein! Da müsste man schon extrem großen Mist bauen, um mehrere Komponenten über Programmgrenzen hinweg zu vermischen.

Das Web ist einfach kein Beispiel für MVC. Im Gegenteil ist es (wie der Artikel ja selbst zugibt) wegen des Request-Response Cycles geradezu unmöglich, MVC über HTTP zu verwenden. Warum wird dann trotzdem an den Bestandteilen des Web so lange herum (fehl-)interpretiert, bis man "M", "V" und "C" jeweils "irgend einem" Bestandteil des Webs zuordnen kann? AlgorithMan (Diskussion) 11:56, 5. Dez. 2014 (CET)

Zu 95% muss ich da zustimmen. Nur der letzte Abschnitt - auch hier stimmt Ihre Aussage - ist aus meiner Sicht zu eng gefasst. Man kann ein Muster auch eine Abstraktionsebene verschieben. (nicht signierter Beitrag von 188.62.58.119 (Diskussion) 16:10, 11. Sep. 2015 (CEST))

Der Artikel IMHO ist seit mindestens 10 Jahren nicht mehr grundlegend überarbeitet worden. Gerade die Webentwicklung hat sich seitdem enorm weiter entwickelt. Nicht meckern, Mut! --79.196.237.38 23:08, 24. Dez. 2015 (CET)

MVC fällt als objektorientiertes Entwurfsmuster allerdings etwas aus dem Rahmen. Es beschreibt eine gröbere Ebene als die typischen objektorientierten Entwurfsmuster. Meiner Meinung nach liegt es auf einer Ebene, auf der es gar nicht mehr um Objekte im strengen Sinne geht. Das Konzept kann man durchaus auch mit anderen Methoden umsetzten. --79.196.237.38 23:08, 24. Dez. 2015 (CET)

Paradoxerweise orientiert sich die heutige Webentwicklung über weite Bereich an MVC, während das Muster in seiner ursprünglichen Domain an Bedeutung verloren hat, auch weil es diese Domain eigentlich nicht mehr gibt. Graphische Interfaces werden in anderen Mustern gedacht. Ich wüsste nicht, dass dabei noch explizit ein Controller programmiert würde. MVC hat einen Bedeutungswandel erlebt. Der Artikel gewichtet das nicht ganz falsch. Gibt wohl einfach niemanden, der noch im historischen Sinne MVC programmiert, und den Bereich vervollständigt. --79.196.237.38 23:08, 24. Dez. 2015 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Steuerung (controller) erste zwei Sätze

Steuerung (controller)

Die Steuerung verwaltet eine oder mehrere Präsentationen, nimmt von ihnen Benutzeraktionen entgegen, wertet diese aus und agiert entsprechend. Zu jeder Präsentation existiert eine eigene Steuerung.

Was gilt jetzt nun?

- Die Steuerung verwaltet eine oder mehrere Präsentationen ....

oder

- Zu jeder Präsentation existiert eine eigene Steuerung. (nicht signierter Beitrag von 188.62.58.119 (Diskussion) 15:38, 11. Sep. 2015 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)

Das Model ist die Connection

Dies ist nur eine Anregung zu weiterführenden Konzepten des MVC Patterns.

Man könnte punkto private Netze einen Frame in den Header einbauen, der mit einem Verschlüsselungsalgorithmus versehen ist und in der Lage ist, zwischen Sender und Empfänger eine generische Schnittstelle aufzubauen. Das heißt das Script, das für die jeweilige API genormt ist ,selbständig erlernt und über lookups die URLs und die Felder ausliest und einfügt. Würde die Verbindung aus mehr als zwei Teilnehmer bestehen, würde die virtuelle Maschine eine Access-violation ausgeben - ergo den Verschlüsselungsalgorithmus in Echtzeit ändern. Damit können private Verbindungen nicht abgehört werden und gleichzeitig müsste man sich nicht um die Datenfelder der Schnittstelle kümmern. Als Core gesehen, bietet diese Anwendung anhand der in der Darstellung generierten Modul-Controler-View auch die Erweiterbarkeit zu Endpunkten von LOD-Datenbanken nach einer Art Time/Availability-Konzept. Bei den Verbindungen könnten die Datenpakete nach einem anderen Verschlüsselungs- verfahren ausgetauscht werden. Diese Vorgänge sind besonders bei Sidechannelattacken notwendig in denen über Synchronisierung zweier ansteigenden Hammig-codierten ansteigenden Datenfelder das auslesen einer Funkübertragung zum Zweck haben. Ich kenne dieses Verfahren noch nicht aber durch die Überprüfung der Checksummen in Datensätzen kann hierdurch der Klartext ausgelesen werden.

Kennt jemand ähnliche Vermutungen? (nicht signierter Beitrag von Georg Neubauer (Diskussion | Beiträge) 18:04, 31. Jul 2016 (CEST))

Archivierung dieses Abschnittes wurde gewünscht von: Sebastian.Dietrich  ✉  17:56, 13. Feb. 2021 (CET)