Was sind die Nachteile von MVC? [geschlossen]

43

Ich benutze MVC / MV *, seit ich vor Jahren angefangen habe, meinen Code zu organisieren. Ich benutze es so lange, dass ich mir keine andere Möglichkeit vorstellen kann, meinen Code zu strukturieren, und jeder Job, den ich nach meinem Praktikum hatte, war MVC-basiert.

Meine Frage ist, was sind die Nachteile von MVC? In welchen Fällen wäre MVC eine schlechte Wahl für ein Projekt und was wäre die (richtigere) Wahl? Wenn ich nach MVC-Alternativen suche, ist fast jedes Ergebnis nur eine andere Art von MVC.

Um den Geltungsbereich einzugrenzen, damit dieser nicht geschlossen wird, sei es für Webanwendungen. Ich arbeite am Backend und Frontend für verschiedene Projekte, also kann ich nicht einfach nur Frontend oder Backend sagen.

Oscar Godson
quelle
5
Es gibt entweder zu viele mögliche Antworten, oder gute Antworten wären zu lang für dieses Format. Fügen Sie Details hinzu, um die Antwortmenge einzugrenzen oder ein Problem einzugrenzen, das in einigen Absätzen beantwortet werden kann.
gnat
8
Ich brauche eine Antwort auf Ihre Definition von MVC, bevor ich auf Ihre Frage antworten kann, da die MVC-Architektur nur für eine Reihe von Problemen gilt. Also, wenn Sie es an der falschen Stelle verwenden, haben Sie einen Sturz.
Ben McDougall
1
Wie vielfältig sind Ihre verschiedenen Berufe?
JeffO
Lesen Sie 'MVC ist nicht objektorientiert' .
Mcintyre321
@JeffO PHP-Apps (Backend, Nicht-JS-Websites), Front-End-Apps. Also alles Web, aber Frontend und Backend.
Oscar Godson

Antworten:

46

Sie sollten immer daran denken - MVC ist ein UI-bezogenes Muster. Wenn Sie eine komplexe Anwendung erstellen, sollten Sie alles, was nicht mit der Benutzeroberfläche zusammenhängt, aus MVC-Drillingen in andere Klassen, Subsysteme oder Ebenen verschieben.

Es war mein größter Fehler. Ich habe lange Zeit diese einfache Regel verstanden:

  • Verteilen Sie ein MVC-Muster nicht auf die gesamte Anwendung.
  • Beschränkt euch nur auf UI-bezogene Dinge.

Überprüfen Sie immer, ob der von Ihnen geschriebene Code logisch an der richtigen Stelle ist, was bedeutet, dass er logisch in den Verantwortungsbereich der Klasse passt, in die Sie ihn einfügen. Wenn nicht, entfernen Sie den Code, sobald Sie ihn verstanden haben.

Alle Muster, die Sie als MVC-Alternativen bezeichnen (dh Model-View-Presenter, Model-View-ViewModel), sind nur eine Möglichkeit, das allgemeine MVC-Konzept zu implementieren.

Hedin
quelle
10
Tatsächlich können Sie MVC jederzeit implementieren, wenn Sie über eine Abstraktionsschicht verfügen. Die API ist die Ansicht / Controller und die zugrunde liegende Logik ist die Modell
Ratsche Missgeburt
14
@ratchetfreak, technisch gesprochen eine API ist eine Form der Benutzeroberfläche, wobei der Benutzer ist der Programmierer der API.
zzzzBov
@ratchetfreak: Wäre dies nicht das Fassadenmuster?
Jeroen Vannevel
2
MVC mag in der Benutzeroberfläche am nützlichsten sein, aber die Trennung von Bedenken ist kaum nur dort nützlich.
DougM
1
@DougM wahr. Genauer gesagt: Der spezifische Separationsstil in MVC wurde für GUI-Anwendungen erstellt. Später wurde das Konzept auf Webanwendungen ausgeweitet, wobei ein großer Teil der Spezifität verloren ging. Die Erweiterung auf API-Designs macht es noch vager. darüber hinaus ... Ich denke, es verliert den größten Teil seines Wertes und es wäre besser, mit dem grundlegenderen (und universelleren) Konzept der Trennung von Anliegen neu zu beginnen.
Javier
17

Meiner Meinung nach gibt es zwei Arten von MVC - reine und unreine (für das Fehlen eines besseren Wortes :)

Pure MVC ist das, was in Small Talk eingeführt wurde:

Bildbeschreibung hier eingeben

Dies war für Personal Computing / Desktop-Anwendungen gedacht. Wie Sie sehen, informiert das Modell die Ansichten über etwaige Aktualisierungen / Änderungen. Nicht so bei (unreinen) MVC.

Die andere (unreine) MVC, die für Webanwendungen angepriesen wird, ist eher ein PAC - Muster ( Presentation-Abstraction-Control ) als die oben beschriebene klassische MVC. Das ist mehr Code-Organisation und Trennung von Bedenken:

  • Modell : Abstraktion für gespeicherte Daten
  • Steuerung : In der Regel die sogenannte Business-Logik-Schicht sowie ein Teil der Anwendung, die für das Weiterleiten der HTTP-Anforderungen an die entsprechende Business-Logik (auch als Controller bezeichnet) verantwortlich ist.
  • Ansicht : Meistens werden Vorlagen angezeigt, mit denen die Daten aus dem Modell formatiert und an den Client zurückgegeben werden. Das Modell sendet NIEMALS Aktualisierungen an die Ansicht und die Ansicht 'abonniert' auch keine Aktualisierungen von einem Modell. Es wäre ein Albtraum. Daher ist es eher PAC als echte MVC.

So ist eine Webanwendung normalerweise aufgebaut:

  1. Front-End : MVC auf dem Client, der Frameworks wie Backbone.js usw. verwendet. Dies ist im Wesentlichen die "wahre" MVC-Form.
  2. Back-End : Auch hier haben Sie (unreine) MVC / PAC für die Code-Organisation und die Trennung von Bedenken
  3. Globale Webanwendung (für die gesamte Webanwendung): Wenn Sie über ein RESTful-Backend verfügen, das nur JSON-Daten zurückgibt, kann Ihr gesamtes Backend als Modell für die Front-End-Client-Anwendung angesehen werden, in der sich View und Controller im Wesentlichen befinden.

Was sind nun einige Nachteile von MVC ? Nun, das Muster hat den Test der Zeit bestanden, so dass es nicht viele gibt, die eine Rolle spielen, außer dass es ein bisschen "kompliziert" ist. Sie sehen, die MVC ist ein zusammengesetztes Muster - implementiert Strategie / Beobachter-Muster und alle sind gut angeordnet, um ein Muster auf hoher Ebene zu bilden.

Solltest du es überall benutzen? Vielleicht nicht. Extrem komplexe Webanwendungen können in mehrere Ebenen aufgeteilt werden! Es kann sein, dass Sie nicht nur mit View / Business Logic / Data-Layern durchkommen. Das übergeordnete Framework / die übergeordnete Organisation kann immer noch MVC-artig sein, jedoch nur auf makroskopischer Ebene.

Hier ist ein Beispiel, in dem MVC für sich allein möglicherweise eine schlechte Wahl ist : Versuchen Sie, ein Flugsicherungssystem oder eine Kredit- / Hypothekenbearbeitungsanwendung für eine große Bank zu entwerfen - MVC für sich allein wäre eine schlechte Wahl. Sie werden zwangsläufig Ereignisbusse / Nachrichtenwarteschlangen sowie eine mehrschichtige Architektur mit MVC innerhalb einzelner Schichten und möglicherweise ein übergreifendes MVC / PAC-Design haben, um die Codebasis besser zu organisieren.

PhD
quelle
+1 für "rein gegen unrein". Ich bevorzuge jedoch die Verwendung von "GUI vs Web MVCs" und verweise darauf, dass GUI MVC modular aufgebaut ist, während Web MVC überlagert ist . Ich wünschte wirklich, die Web-MVC würde etwas anderes heißen, da sie sich von der "reinen MVC" zu stark unterscheidet, aber es scheint zu spät dafür zu sein.
Javier
Ich mag das Diagramm. Re. die Formulierung, vielleicht "traditioneller MVC vs abgeleitet MVC" :)
Edwin Yip
12

Der Fehler, den viele Leute mit Designmustern machen, besteht darin, dass sie an einem Ort wunderbar funktionieren und dann versuchen, sie überall anzuwenden.

Wenn Sie eine Weile an einem Ort gearbeitet haben, können Sie einen Teil des Codes fast datieren, indem Sie sehen, welche Technologien / Entwurfsmuster / Praktiken zu der Zeit in Mode waren, z. B. Singletons / Abhängigkeitsinjektion / TDD usw. usw.

Wie für wo man es nicht benutzt. Nun, wo immer ein Element des MVC-Triplets nicht zutrifft. Konsolenanwendungen implementieren möglicherweise überhaupt keine Schnittstelle. Hilfsprogramme haben möglicherweise kein Modell. Und wenn Sie weder ein Modell noch eine Ansicht haben, benötigen Sie wahrscheinlich keinen Controller.

Das Problem liegt selten beim Konzept, sondern bei der Umsetzung. Egal wie gut das Paradigma ist, nehmen Sie sich die Zeit, um zu prüfen, ob es für das jeweilige Problem geeignet ist.

Robbie Dee
quelle
2
Wenn MVC ordnungsgemäß befolgt wird, kann der Code erneut verwendet werden. Dieselbe Logik hinter einem Dienstprogramm oder Befehlszeilenprojekt kann leicht ein identischer Controller aus einem größeren Programm mit einem alternativen Modell und einer alternativen Ansicht sein. (Dies ist möglicherweise nicht der EFFIZIENTESTE Code, aber das ist nicht immer ein
Problem
Die Konsole ist eine Benutzeroberfläche. Nur textbasiert, daher ist Ihre Annahme falsch.
GuardianX
@GuardianX Ich habe das gar nicht so gut ausgedrückt. Ich habe meine Antwort zur Klarstellung bearbeitet.
Robbie Dee
3

MVC ist wie jedes Paradigma, das nicht Teil Ihrer Entwicklungsplattform ist, komplexer. Es ist ein Nachteil, dass Sie möglicherweise Klassen trennen, die nicht getrennt werden sollten, und die Klarheit darüber verlieren, wie eng sie miteinander verbunden sind. (Oder für triviale Projekte, die sogar Ihren Code verschleiern.)

Die Alternative für das erste Problem besteht darin, solchen Code in unabhängige Unterprojekte aufzuteilen. Die Alternative für die Sekunde ist nicht separierter Code, entweder in der Klasse oder im Dateimodell.

DougM
quelle
+1 für die Erwähnung kleinerer Projekte, obwohl ich es zu schätzen weiß, dass es hier verschiedene Denkschulen gibt. Einige würden sagen, dass ein POC, wenn es eine Chance gibt, sich in Live-Code zu verwandeln, richtig geschrieben werden sollte. Während andere behaupten, es sei besser, etwas zusammen zu rauen und dann von vorne zu beginnen, wenn das Projekt voranschreitet, als Zeit damit zu verschwenden, etwas zu polieren, das niemals verwendet werden könnte.
Robbie Dee
@ Robbie: ahh !! Feature schleichen!
DougM
0

Mein Verständnis für die Anwendung von MVC / MV * beruht auf dem Prinzip der Trennung von Anliegen (Separation of Concerns, SoC) - Trennung von Programmen / Codes in separate Abschnitte / Teile, sodass jeder Abschnitt ein separates Anliegen behandeln kann (siehe http://en.wikipedia.org) / wiki / Trennung von_Anliegen )

Es gibt viele Vorteile bei der Trennung von Bedenken: Eine hat keinen Einfluss auf die andere, und Entwickler können an einer Einheit arbeiten, ohne den Rest zu beeinträchtigen usw. & etc ... MVC ist nicht das einzige Muster, das SoC folgt. Im Grunde genommen ist OOP selbst das gleiche Ein großartiges Konzept, um Dinge in Einheiten zu unterteilen.

MVC / MV * sind sehr nützlich, wenn Sie mit der Entwicklung von Benutzeroberflächen befasst sind. Darunter befinden sich möglicherweise weitere Muster - Factory, Singleton, Fassade usw. Die meisten großen Projekte bestehen aus mehreren Ebenen, die unterschiedliche Aspekte behandeln. Die Benutzeroberfläche ist jedoch möglicherweise kein Muss manche Fälle. Möglicherweise sehen Sie MVC sehr oft, weil viele Projekte UI-Elemente haben.

Während Sie über die Nachteile von MVC sprechen, hängt es wirklich von den Projekten ab, die Sie gerade durchführen - hat es eine Benutzeroberfläche? erfordert es große Skalierbarkeit / Erweiterbarkeit? Gibt es viele Wechselwirkungen zwischen der Benutzeroberfläche und dem Hintergrundsystem? Für eine einfache Informationswebseite ist beispielsweise überhaupt keine MVC erforderlich, es sei denn, Sie planen, sie in Zukunft auf eine großartige interaktive Seite auszudehnen.

Um MVC (oder allgemeiner - ein Entwurfsmuster) zu bewerten, geben Sie ihm einen Kontext und denken Sie über Komplexität, Skalierbarkeit, Testbarkeit, Wartung, Zeitbeschränkung usw. & usw. nach.

Rex
quelle