it-swarm-eu.dev

Warum sollte ich ein MVC-Muster verwenden?

Es scheint, dass heutzutage jeder, der Webanwendungen ausführt, MVC für alles verwenden möchte. Es fällt mir jedoch schwer, mich davon zu überzeugen, dieses Muster zu verwenden. Ich verstehe, dass die allgemeine Idee darin besteht, die Backend-Logik vom Frontend zu trennen, das das Programm darstellt. Im Allgemeinen scheinen die Ansichten immer in gewissem Maße vom Controller abhängig zu sein, was je nach Modell endet. Ich sehe keinen Vorteil für mich, wenn ich den Controller hinzufüge. Ich habe viel Hype über "So sollten Anwendungen entworfen werden" gelesen, aber vielleicht verstehe ich immer noch nicht, was wohin gehen 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 die Verwendung von MVC, wenn nur das Frontend von der Backend-Logik getrennt wird? (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 eines separaten "Controllers".)

75
Billy ONeal

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

Ich finde es nicht besonders nützlich, sich MVC als Muster vorzustellen, da es einige verschiedene Ideen enthält. Verschiedene Leute, die an verschiedenen Orten über MVC lesen, nehmen unterschiedliche Ideen davon und beschreiben diese als "MVC". Wenn dies nicht genug Verwirrung stiftet, entstehen Missverständnisse von MVC, die sich durch ein System chinesischer Flüstern entwickeln.

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

Das Herzstück von MVC ist das, was ich als separate Präsentation bezeichne. 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 sind, die wir auf dem Bildschirm sehen. Domänenobjekte sollten vollständig in sich geschlossen sein und ohne Bezugnahme auf die Präsentation funktionieren. Sie sollten auch mehrere Präsentationen unterstützen können, möglicherweise gleichzeitig.

Sie können Fowlers gesamten Artikel lesen hier .

50
Gnawme

Ich denke, 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 beispielsweise 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 Aktion, die stattfindet und die auf konzeptioneller Ebene ausgeführt werden muss. Welche Phasen muss ich beispielsweise durchlaufen, um einem Benutzer eine Rechnung zu stellen? N.B. Dies kann sich auf eine beliebige Anzahl von Objekten auswirken, weiß jedoch nichts darüber, wie sie in der Datenbank gespeichert werden.

View - Wie rendere ich das Ergebnis?

Das Problem, das Sie meiner Meinung nach sehen, ist, dass viele Webanwendungen eine verherrlichte CRUD-Schnittstelle (Create-Retrieve-Update-Delete) zu einer Datenbank sind. d.h. der Controller wird angewiesen, "einen Benutzer hinzuzufügen", und er weist das Modell dann einfach an, "einen Benutzer hinzuzufügen". Es wird nichts gewonnen.

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

19
Unk

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 Logik erforderlich ist, die nicht unbedingt in ein Modell passt (z. B. URL-Chunks zum Parsen von Baumdurchläufen).

Ich kam von CI und Yii und fand es eine wirklich coole Idee, einen dedizierten Controller zu haben. Bei der Entwicklung von Anwendungen mit geeigneten RESTful-Schnittstellen scheint sich jedoch die Notwendigkeit zu verringern, dass ein Controller nicht modellspezifische Logik verarbeitet. Als ich zu Django und dann zu Pyramid (von denen keines vollständig der MVC-Architektur folgt) wechselte, stellte ich fest, dass der Controller tatsächlich keine erforderliche Komponente für die von mir erstellten Anwendungen war. Beachten Sie, dass beide Frameworks haben "Controller'ish" -Funktionen wie URL-Dispatching in Pyramid, aber es ist eine Konfigurationssache, keine Laufzeitsache (wie CController in Yii).

Am Ende des Tages ist wirklich wichtig die Trennung von Sicht und Logik. Dies bereinigt nicht nur die Implementierung, sondern ermöglicht es FE/BE-Ingenieuren auch, parallel zu arbeiten (wenn sie in einer Teamumgebung arbeiten).

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

8
Demian Brecht

Ja, die Terminologie hierfür ist ein Chaos. Es ist schwer darüber zu reden, weil man nie ganz weiß, was jemand bedeutet mit den Begriffen.

Was den Grund für einen separaten Controller betrifft, 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 einen Stub oder Mock verwenden können, um andere Dinge zu testen. Wenn Sie jedoch Ihre konkrete Ansicht selbst testen, ist dies schwieriger. Wenn Sie einen Controller hatten, auf dem nicht Widgets denselben Code ausführen, können Sie dies direkt testen und müssen die Widgets möglicherweise nicht per Skript testen.

Die anderen Versionen sind meiner Meinung nach schwerer einen konkreten Nutzen zu zeigen. Ich denke, es handelt sich hauptsächlich um ein Problem der Trennung von Bedenken - trennen Sie rein visuelle GUI-Bedenken von der Logik, die für die GUI gilt, aber nicht Teil des Geschäftsmodells ist (z. B. übersetzen Sie Aktualisierungen aus dem Modell, in das Widgets sichtbar sein sollten). In der Praxis sind die beiden Klassen jedoch wahrscheinlich so eng miteinander verbunden (selbst wenn sie über Schnittstellen kommunizieren), dass es schwierig ist, sie zu einer Ansicht zusammenzufassen und nach Möglichkeiten zu suchen, wie die Funktionalität wiederverwendbarer sein kann wenn sie gespalten wären.

1
psr

Einfach ausgedrückt: Trennung von Bedenken. Abgesehen von all dem Gerede über die "richtige" Vorgehensweise, saubereren Code usw. können Sie einfach sagen, dass Sie mit MVC Ihren Code einfacher wiederverwenden können. Grundsätzlich programmieren Sie Ihre Modelle und Controller und können sie undeutlich in einer Web-App, einer Desk-App, einem Service überall ohne großen Aufwand verwenden.

0
AJC