Warum sollte ich ein MVC-Muster verwenden?


74

Heutzutage scheint jeder, der Webanwendungen erstellt, MVC für alles nutzen zu wollen. Es fällt mir jedoch schwer, mich von diesem Muster zu überzeugen. Ich verstehe die allgemeine Idee ist, die Backend-Logik vom Frontend zu trennen, das das Programm darstellt. Im Allgemeinen scheint es, dass die Ansichten immer in gewissem Maße vom Controller abhängen, was letztendlich vom Modell abhängt. Ich verstehe nicht, welchen Vorteil mir das Hinzufügen des Controllers bringt. Ich habe viel Hype darüber gelesen, wie Anwendungen so gestaltet werden sollten, aber vielleicht verstehe ich immer noch nicht, was wohin soll. Wann immer ich mit anderen über MVC spreche, scheint jeder eine andere Vorstellung davon zu haben, was in welche Kategorie gehört.

Warum sollte ich MVC verwenden? Was bringt mir MVC, wenn ich nur das Frontend von der Backend-Logik trenne? (Die meisten "Vorteile", die ich von diesem Muster sehe, werden nur durch die Trennung der Schnittstelle von der Implementierung erzielt und erklären nicht den Zweck, einen separaten "Controller" zu haben.)


9
MVC ist einfach eine Implementierung von Separation of Concerns . Jede Implementierung ist ausreichend. Das Nichtverwenden von Seperations of Concerns führt in der
Regel

1
@ Raynos: Vielleicht. Aber genau hier setzt der "Hype" nicht an.
Billy ONeal

3
Der Hype folgt der Hype-Kurve . Lass dich nicht zu sehr beeinflussen. Aus meiner Sicht ist MVC eine solide Architektur für SoC und einfach zu implementieren. Ich kann mir keine solide Alternative vorstellen.
Raynos

die meisten bestehenden User-Interface - Frameworks fest Link V und C , und wenn Sie zu einem anderen wechseln werden Sie sowohl die Ansicht und Controller (die Schnittstelle von M auf das , was der Benutzer sieht) neu zu schreiben müssen
Ratsche Freak

Die Trennung von Bedenken ist jedoch eine Eigenschaft der OO-Entwicklung. Sie müssen kein MVW-Muster verwenden, um einen korrekten Code für die Trennung von Interessen zu implementieren?
Bastien Vandamme

Antworten:


50

Heh. Martin Fowler stimmt Ihrer Verwirrung über MVC zu:

Ich finde es nicht besonders nützlich, MVC als Muster zu betrachten, da es eine ganze Reihe verschiedener Ideen enthält. Verschiedene Leute, die an verschiedenen Orten über MVC lesen, nehmen unterschiedliche Ideen daraus und bezeichnen diese als "MVC". Wenn dies nicht genug Verwirrung stiftet, kommt es zu Missverständnissen von MVC, die durch ein System chinesischer Flüstern entstehen.

Er gibt jedoch eine der überzeugenderen Erklärungen, was MVC motiviert:

Das Herzstück von MVC ist das, was ich Separated Presentation nenne. Die Idee hinter Separated Presentation ist eine klare Trennung zwischen Domänenobjekten, die unsere Wahrnehmung der realen Welt modellieren, und Präsentationsobjekten, die die GUI-Elemente darstellen, die wir auf dem Bildschirm sehen. Domänenobjekte sollten vollständig eigenständig sein und ohne Bezug zur Präsentation funktionieren. Sie sollten auch in der Lage sein, mehrere Präsentationen, möglicherweise gleichzeitig, zu unterstützen.

Sie können den gesamten Artikel von Fowler hier lesen .


19

Ich glaube, das hängt stark von dem Problem ab, mit dem Sie sich befassen. Ich sehe die Trennung wie folgt:

Modell - wie stellen wir die Daten dar? Wie gehe ich zum Beispiel von meinen Objekten zu einem dauerhaften Speicher wie einer Datenbank -> wie speichere ich mein 'Benutzer'-Objekt in der Datenbank?

Controller - was mache ich? Dies ist die Handlung, die stattfindet und die auf konzeptioneller Ebene ausgeführt werden muss. In welchen Schritten muss ich beispielsweise einen Benutzer in Rechnung stellen? Hinweis: Dies kann sich auf eine beliebige Anzahl von Objekten auswirken, weiß jedoch nichts darüber, wie diese in der Datenbank gespeichert werden.

Ansicht - wie rendere ich das Ergebnis?

Das Problem, das ich sehe, ist, dass viele Webanwendungen eine verherrlichte CRUD-Schnittstelle (Create-Retrieve-Update-Delete) zu einer Datenbank sind. Das heißt, der Controller wird angewiesen, einen Benutzer hinzuzufügen, und das Modell wird einfach angewiesen, einen Benutzer hinzuzufügen. Es wird nichts gewonnen.

In Projekten, in denen die von Ihnen ausgeführten Aktionen nicht direkt auf Änderungen im Modell zutreffen, vereinfacht ein Controller das Leben erheblich und das System ist wartungsfreundlicher.


1
"In Projekten, in denen die von Ihnen ausgeführten Aktionen nicht direkt auf Änderungen im Modell zutreffen" Was meinen Sie hier mit "Modell"? Die Datenbank? Denn jeder, mit dem ich gesprochen habe, sagt, dass solche Aktionen immer noch zu einem Modell gehören, nicht zu Controllern. (zB, dass Controller sich nur mit HTTP-
Dingen

Was zählt als HTTP-Zeug? Ich würde Folgendes in einen Controller einbeziehen: Aufheben der Zuordnung von HTTP-Anforderungsparametern, Überprüfen der Parameter auf grundlegende Integrität, Ermitteln der erforderlichen Schritte, Aufrufen geeigneter Modellobjekte (Lesen, Schreiben oder beides) und Erstellen eines Endergebnisses basierend auf den Antworten des Modells und gab das an die Aussicht weiter. Ein albernes Beispiel für etwas, für das nur ein Controller verwendet wird, könnte ein Webdienst sein, der eine Zufallszahl generiert - in diesem Fall gibt es kein 'Modell', das man sich ansehen kann (zumindest in meinen Augen ...)
Unk

Das sind alles Modellbedenken. Sogar "entscheiden, was getan werden muss" (der "Frontcontroller") ist ein Modell.
Billy ONeal

2
Ganz zu schweigen von Controllern, die hilfreich sind, um Ihre Modelle nicht fest mit Ihren Ansichten zu verbinden. Sie können nicht nur viele Ansichten mit vielen Modellen über einen Controller verbinden.
Raynos

1
@Billy: Wenn Sie einer Ansicht erlauben, sich mit dem Modell zu "vermischen" - anstatt es nach seinen Werten zu fragen -, erhalten Sie Ansichten, die eher wie Controller aussehen. Ich denke eher an die Model-GUI-Mediator-Inkarnation von MVC. Der Controller vermittelt zwischen dem Modell (Verhalten und Daten der Domäne) und der grafischen Benutzeroberfläche (Bildschirmdarstellung des Modells). Die Ansicht übergibt nur Interaktionen an den Controller (Benutzer hat geklickt ...). Der Controller entscheidet, was (falls vorhanden) für das Modell aufgerufen werden muss. Vorteile: ...
Marjan Venema

8

Das solltest du nicht.

Lassen Sie mich das umformulieren. Sie sollten eine Architektur verwenden, die die Logik von Ihren Ansichten trennt. Bei Bedarf sollten Sie eine Architektur verwenden, die einen Controller verwendet (z. B. MVC), wenn eine Logik erforderlich ist, die nicht unbedingt in ein Modell passt (z. B. URL-Chunks für das Tree Traversal Parsing).

Ich stamme von CI und Yii und fand, dass ein dedizierter Controller eine wirklich coole Idee ist. Bei der Entwicklung von Anwendungen mit geeigneten REST-Schnittstellen scheint sich jedoch die Notwendigkeit zu verringern, dass ein Controller nicht modellspezifische Logik handhabt. Bei der Umstellung auf Django und dann Pyramid (von denen keine vollständig der MVC-Architektur entspricht) stellte ich fest, dass der Controller keine erforderliche Komponente für die von mir erstellten Anwendungen war. Beachten Sie, dass beide Frameworks über "controller'ish" -Funktionen verfügen, z. B. URL-Dispatching in Pyramid, aber dies ist eine Konfigurationssache, keine Laufzeitsache (wie z. B. CController in Yii).

Am Ende des Tages ist es wirklich wichtig, den Blick von der Logik zu trennen. Dies räumt nicht nur in Bezug auf die Implementierung auf, sondern ermöglicht es auch FE / BE-Ingenieuren, parallel zu arbeiten (wenn sie in einer Teamumgebung arbeiten).

(Randnotiz: Ich entwickle Web-Apps nicht professionell, daher fehlt mir möglicherweise etwas.)


Ich stimme vollkommen zu, gute Antwort. Der Controller ist nicht immer erforderlich, sondern nur als Strategie für die Kommunikation der Ansicht mit dem Modell gedacht.
Falcon

@ Falcon: Sehen Sie, das ist meine Verwirrung. Ich habe mehr als eine Person sagen sehen, dass die Ansicht überhaupt nicht mit dem Controller sprechen sollte. dass es nur mit dem Modell sprechen sollte ...
Billy ONeal

1
Wenn Sie eine tatsächliche MVC-Implementierung verwenden, kommuniziert die Ansicht nicht mit dem Controller (oder dem Modell). Der Controller legt den Status des Modells fest, bereitet die Daten für die Ansicht vor und überträgt sie in die Ansicht.
Demian Brecht

@Demian: Ich habe das Gegenteil gehört (dass Controller effektiv nichts tun sollten). Häufig. Das ist mein größtes Problem mit diesem Muster; niemand scheint sich darüber einig zu sein, was es ist.
Billy ONeal

3
Ja, ich habe oft gehört, dass Sie, wenn Sie 10 Programmierer in einem Raum haben, 9 verschiedene Definitionen von MVC erhalten. Wirklich ist der Hauptpunkt die Trennung der Interessen. Was sonst noch passiert, scheint eine religiöse Debatte zu sein.
Demian Brecht

1

Ja, die Terminologie dazu ist ein Chaos. Es ist schwer darüber zu reden, weil man nie genau weiß , was jemand mit den Begriffen meint .

Was die Gründe für einen separaten Controller angeht, hängt der Grund möglicherweise davon ab, von welcher Controller-Version Sie sprechen.

Möglicherweise möchten Sie einen Controller, da die Ansicht beim Ausführen von Tests eine Reihe von Widgets enthält, die Sie nicht geschrieben haben und wahrscheinlich nicht testen möchten. Ja, Sie haben die Implementierung von der Vererbung getrennt, sodass Sie andere Dinge mit einem Stub oder Mock testen können. Wenn Sie jedoch Ihre konkrete Ansicht selbst testen, ist dies schwieriger. Wenn Sie einen Controller hatten, auf dem keine Widgets mit demselben Code ausgeführt wurden, können Sie dies direkt testen und müssen die Widgets möglicherweise nicht über ein Skript testen.

Für die anderen Versionen ist es meiner Meinung nach schwerer, einen konkreten Nutzen zu zeigen. Ich denke, es ist hauptsächlich ein Problem der Trennung von Bedenken - trennen Sie rein visuelle GUI-Bedenken von der Logik, die auf die GUI zutrifft, aber nicht Teil des Geschäftsmodells ist (z. B. Übersetzen von Aktualisierungen aus dem Modell, in die Widgets sichtbar sein sollen). In der Praxis sind die beiden Klassen jedoch wahrscheinlich so eng miteinander verbunden (auch wenn sie über Schnittstellen kommunizieren), dass es schwierig ist, sie zu einer Ansicht zusammenzuführen und zu prüfen, ob die Funktionalität wiederverwendbarer ist wenn sie gespalten wären.


0

Einfach ausgedrückt: Trennung von Bedenken. Abgesehen von all dem Gerede über die "richtige" Art, Dinge zu tun, saubereren Code zu haben usw. können Sie einfach sagen, dass MVC es Ihnen ermöglicht, Ihren Code einfacher wiederzuverwenden. Grundsätzlich programmieren Sie Ihre Modelle und Ihre Steuerungen und können sie undeutlich in einer Web-App, einer Desk-App, einem Service und an jedem Ort ohne großen Aufwand verwenden.


2
Das ist nichts anderes, als einfach eine UI-Ebene und eine funktionale Ebene zu definieren. Sie haben nicht erklärt, warum das Controller-Bit erforderlich ist.
Billy ONeal

-3

Nun, der Grund für die Verwendung einer MVC-Struktur zeigt sich in einem Branchen-Setup, in dem ein einzelner Arbeitsprozess und ein einzelnes Modell für die Entwicklung einer beliebigen Anwendung verwendet werden. Wenn das Projekt also von einem Modul einer Organisation in ein anderes übergeht, ist es viel einfacher, das Arbeitsszenario besser zu verstehen. Es beinhaltet Klarheit der Arbeit.
Während Sie als Einzelperson einen anderen Ansatz für Ihre Bewerbung haben würden, würden Sie, wenn Sie in einer kombinierten Art und Weise mit einem Mitarbeiter arbeiten, zuerst ein gemeinsam vereinbartes Modell zwischen den beiden (Ihnen und Ihrem Mitarbeiter) diskutieren und darauf aufbauen. In einem solchen Fall werden die Ihnen und Ihrem Mitarbeiter zugewiesenen Verantwortlichkeiten durch einen deutlichen Spielraum voneinander getrennt.


-3

Ich denke, MVC wird nur als Schlagwort von Theoretikern verwendet, die Manager sind. Die derzeitige Iteration des Webs mit HTML5, das sich durch ein ansprechendes Design auszeichnet, und der Versuch, eine einzige Zeile der Datenbankprogrammierung zu erstellen, die im Web und auf einem iPhone funktioniert, bietet sich jedoch für die allgemeinen Ideen von MVC an. Die Web-Front-End-Technologie bewegt sich mit Jquery, neuen Iterationen der CSS-Steuerung, im wahrsten Sinne des Wortes mit Lichtgeschwindigkeit, während sich die Serverseite im Schneckentempo bewegt.

Letztendlich handelt es sich auf dem Server nur um Dienste oder "Applets", die Daten an das Front-End senden. Je nachdem, welchen Client Sie haben, werden diese Daten unterschiedlich verarbeitet und angezeigt. In diesem Sinne macht MVC Sinn.

In dieser Hinsicht glaube ich, dass die MVVM in der gegenwärtigen realen Welt ein wirklich besseres "Muster" ist, oder wie auch immer Sie es nennen möchten, als ein Controller, da ein Controller immer zum Modell zurückkehren muss, um die Ansicht zu ändern, und dies ist langsam . Im MVVM-Muster kann das ViewModel die Ansicht sofort aktualisieren. Darüber hinaus fördert das MVVM-Modell RESTful Design Principals IMHO.


Ist das nur deine Meinung, oder kannst du es irgendwie bestätigen?
15.

3
(hat nicht abgelehnt) Nun, es ist seit über 40 Jahren ein Modewort, wenn es so ist.
Billy ONeal

2
Ich möchte Sie ermutigen, einige zusätzliche Untersuchungen zu den Ursprüngen des MVC-Musters und den zusätzlichen Mustern, die es hervorgebracht hat, wie MVP und MVVM, anzustellen. Das Muster hat viel mehr Geschichte, als die aktuelle Modewelt vermuten lässt.

1
Aus der Model View Controller-Geschichte : "MVC wurde in den 70er Jahren im Xerox Parc erfunden, anscheinend von Trygve Reenskaug. Ich glaube, sein erster öffentlicher Auftritt war in Smalltalk-80. Lange Zeit gab es praktisch keine öffentlichen Informationen über MVC, auch nicht in Smalltalk -80 Dokumentation Das erste wichtige Papier, das in MVC veröffentlicht wurde, war "Ein Kochbuch für die Verwendung des Modell-Ansicht-Controller-Benutzeroberflächen-Paradigmas in Smalltalk -80" von Glenn Krasner und Stephen Pope, veröffentlicht in der August / September 1988-Ausgabe des JournalOfObjectOrientedProgramming (JOOP). "

Es gibt viele viel wichtigere Schlagworte wie KISS, die es schon länger gibt und die viel WENIGER Aufmerksamkeit bekommen.
Michael Barber
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.