Gilt MVC nur für das Web

Es ist fast und sofort, wenn ich mit Entwicklern über Model View Controller ( MVC ) spreche, dass sie eine Anfrage an eine URL stellen, der Server eine Entität (MODEL) erstellt und Ihnen eine visuelle Darstellung dieses Modells bereitstellt.

• Bedeutet dies, dass MVC nur für das Web gedacht ist, oder habe ich Leute getroffen, die nur Entwickler sind, die MVC zum Schreiben von Webanwendungen einsetzen?

• Gibt es Verwendungsmöglichkeiten für MVC in Desktop-Anwendungen?

• Ich für meinen Teil bin ein Paradigma-Neuling und würde gerne wissen, welche Super-Sets MVC anbietet

MVC ist ein Muster. Muster gelten für die gesamte Programmierung. MVC funktioniert einfach sehr gut in einem Webkontext.

Wie gnat bemerkt, schauen Sie sich einfach das mvc-Tag an und Sie werden mehrere Beispiele dafür sehen, wie es implementiert wird.

Wenn man bedenkt, dass MVC aus dem Jahr 1977 stammt und das Web erst 1991 erfunden wurde, sollte es ziemlich offensichtlich sein, dass MVC nicht nur für das Web ist.

Nein, bei der Entwicklung für OS X und iOS wird das Model View Controller-Muster verwendet.

Stellen Sie die Frage in einer Microsoft-Umgebung, und viele Leute gehen davon aus, dass Sie Asp.Net MVC meinen, eine MVC-Implementierung speziell für das Web.

Leider gibt es viele Leute, die nicht erkennen, dass dies eine Implementierung des MVC-Musters ist, und sie denken, dass sie austauschbare Begriffe sind, was zu einer Annahme von "nur Web" führt.

Soweit ich weiß, war die erste Implementierung von MVC in Smalltalk. Es war definitiv in Smalltalk-80 vorhanden. Obwohl ich keine Dokumentation zur Hand habe, um dies zu beweisen, glaube ich, dass es bis dahin einige Jahre lang in Smalltalk war (oder so ähnlich).

Die meisten OO-GUI-Frameworks enthalten mindestens eine Variante von MVC. Ich bin mir jedoch nicht sicher, was genau "Obermenge" in diesem Fall bedeuten würde. Es ist ein wenig schwer zu sagen, ob eine bestimmte Variante eine Obermenge, eine Untergruppe oder ein Peer von MVC ist, aber ich würde die meisten von ihnen eher als Peers bezeichnen.

Auf jeden Fall wurden viele (die meisten?) Für die Desktop-Entwicklung verwendet, nicht für die Web-Entwicklung. Dank einiger alter AT & T-Patente benötigen die meisten Fenstersysteme Programme, um bei Bedarf neue Ansichten generieren zu können. Dies erzwingt (fast) zumindest einen gewissen Grad an Trennung zwischen Code, der den aktuellen Status (das Modell) beibehält, und Code, der diesen Status (die Ansicht) anzeigt. Das lässt immer noch viel Spielraum für Variationen in Bezug auf 1) den Grad der Isolation der Reglerfunktionalität und 2) die genauen Details, wo die Linien zwischen den einzelnen Hauptteilen gezogen werden sollen.

Nein, es gilt auch für Standalone-Anwendungen. Beispiel Java Swing folgt MVC.

Daher gibt es in diesem Bereich viele verschiedene Designmuster.

• Model View Presenter (mvp)
• Modellansicht Presenter anzeigen (MVVP)
• Model View Controller
• Modell 2

und so weiter. Im Laufe der Jahre wurden diese miteinander verflochten, zusammengefügt, verändert und in einer Vielzahl von Zusammenhängen angewendet. Wichtig dabei ist, dass sich das MVC-Entwurfsmuster von 1977 stark verändert hat und nicht mehr das Entwurfsmuster ist, das von serverseitigen Webframeworks verwendet wird. Als Beispiel in der ursprünglichen Smalltalk-Implementierung würde das Modell die Ansicht auf Änderungen beobachten, was nicht mehr der Fall ist, da die Serverseite HTML-Elemente im Browser des Benutzers einfach nicht beobachten kann. Wenn sich die Ansicht ändert, sendet die Ansicht stattdessen eine Anforderung an die Steuerung, die dann die Ansicht aktualisiert. Auch hier wird die ursprüngliche MVC-Implementierung nicht befolgt, da eine Aktualisierung des Modells bedeuten würde, dass alle vom Modell abhängigen Ansichten aktualisiert würden.

Die modernen Web-Frameworks folgen einer einfachen dreistufigen Architektur, die auch als Modell 2-Architektur bezeichnet wird.

Es gibt natürlich Beispiele für echte MVC-Architekturen im Web, aber diese sind oft nur clientseitig und mit einem Server verbunden, der der Model 2-Architektur folgt, da die Ansichten xml und json sind und nicht auf Änderungen überprüft werden. Beispiele für clientseitige reine MVC-Architekturen sind Sencha Touch und Sproutcore.

Wenn Sie MVC im Browser, MVC wie auf dem Server und MVC wie als Datenebene haben, haben Sie eine hierarchische MVC-Implementierung.

Hinweis. Ich habe nur über Web-Frameworks gesprochen, andere Implementierungen von MVC wie Java Swing und Flex haben andere Implementierungsunterschiede.

Eine Sache, die Sie wissen müssen, ist, dass es so viele MVC-Varianten gibt, wie es Frameworks gibt, die behaupten, MVC zu implementieren.

Die meisten stimmen darin überein, dass das Modell einen bestimmten Status hat und die Ansicht ihn wiedergibt. Der Controller hat jedoch sehr unterschiedliche Rollen.

In Smalltalk, wo es zuerst beschrieben wurde, ist das Modell der Kern Ihrer Anwendung, Daten und Geschäftsmethoden. Die Ansicht ist eine grafische Darstellung des Status der Anwendung (auch bekannt als Modell), und der Controller verwaltet die Benutzereingaben sowie Maus- und Tastaturereignisse. Der Controller leitet beispielsweise Tastaturereignisse an das Ansichtselement weiter, das den Fokus hat.

Auf .jsp-Seiten besteht das Modell hauptsächlich aus Daten, die Ansicht gibt das Modell in HTML wieder und der Controller leitet das Modell an die richtige Ansicht weiter, um es zu rendern.

Um Ihre Frage zu beantworten: MVC wird sowohl in eigenständigen Anwendungen (Java, .Net, Flex) als auch im Web (JSP-Seiten) verwendet. Dies bedeutet, dass die von Ihnen bekannte MVC nicht in eigenständigen Anwendungen verwendet wird.