Was sind die Nachteile von MVC? [geschlossen]

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.

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.

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:

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.

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.

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.

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.