wake-up-neo.com

Was sind die Hauptvorteile des MVC-Musters gegenüber dem altmodischen 3-Schicht-Muster?

Ich denke darüber nach, ein MVC-Muster in meinem neuen Projekt zu verwenden, und ich kann deutlich den großen Vorteil erkennen, dass ich die Datenebene (das Modell) etwas näher an die Präsentationsschicht (die Ansicht) setzen kann, was eine kleine Steigerung ermöglicht in der Anwendungsgeschwindigkeit. Gibt es außer dem Performance-Standpunkt andere Vorteile von MVC gegenüber dem Mustermuster mit View-Logic-Daten?

EDIT: Für Interessierte habe ich gerade einen Beispielcode PHP hochgeladen, den ich erstellt habe, um die Verwendung von MVC zu testen. Ich habe bewusst alle Sicherheitsprüfungen weggelassen, um den Code ein wenig lesbarer zu machen. Bitte kritisieren Sie es nicht zu sehr, da ich weiß, dass es viel verfeinerter und fortgeschrittener sein könnte, aber trotzdem - es funktioniert !!! Ich freue mich über Fragen und Anregungen: Hier ist der Link: http://www.sourcecodester.com/sites/default/files/download/techexpert/test_mvc.Zip

31
techexpert

Die Trennung von Bedenken, die als Vorteil von MVC angeführt wird, ist tatsächlich auch ein Fortschritt eines 3-Schicht-/3-Schicht-Systems. Auch hier ist die Geschäftslogik unabhängig und kann von verschiedenen Darstellungsstufen verwendet werden.

Ein Hauptunterschied besteht darin, dass das Modell in der klassischen MVC einen Verweis auf die Ansicht haben kann. Dies bedeutet, dass das Modell bei einer Aktualisierung der Daten diese Daten möglicherweise in mehrere Ansichten zurückschieben kann. Das Paradebeispiel ist eine Desktop-Anwendung, bei der Daten auf verschiedene Weise visualisiert werden. Dies kann so einfach wie eine Tabelle und ein Diagramm sein. Eine Änderung in der Tabelle (die eine Änderung in einer Ansicht darstellt) wird zuerst über die Steuerung zum Modell geschoben, das dann in die Grafik (die andere Ansicht) zurückgeschoben wird. Die Grafik wird dann selbst aktualisiert.

Da die Desktop-Entwicklung rückläufig ist, haben viele Programmierer nur in einigen Web-Varianten mit MVC in Kontakt gekommen, z. über JSF in Java EE.

In diesen Fällen hat das Modell fast nie einen Bezug zur Ansicht. Dies liegt daran, dass das Web hauptsächlich auf Anfragen/Antworten basiert. Nachdem eine Anfrage bearbeitet wurde, kann der Server keine zusätzlichen Informationen senden. D.h. Ein Update, das vom Modell an den Client übertragen wurde, wäre bedeutungslos. Mit Reverse Ajax/Comet ändert sich dies, aber viele webbasierte MVC-Frameworks nutzen dies immer noch nicht vollständig.

Im Fall einer webbasierten MVC ist das typische "Dreieck" zwischen M, V und C weniger dort und diese MVC-Variante ist tatsächlich näher an einem n-Tier-Modell als "wahre" MVC.

Beachten Sie auch, dass einige MVC-Frameworks im Web einen dazwischen liegenden Installationsabschnitt zwischen M, V und C aufweisen, der als Backing Bean (Java/JSF) oder als Code dahinter (ASP.NET) bezeichnet wird. In JSF wird der Controller vom Framework bereitgestellt, und die Sicht bindet sich oft nicht direkt an das Modell, sondern verwendet dieses Backing Bean als Intermediär. Das Backing-Bean ist sehr schlank und holt im Grunde nur Daten auf eine Weise aus dem Modell und übersetzt modellspezifische Nachrichten (z. B. Ausnahmen) in sichtspezifische Nachrichten (z. B. einen für Menschen lesbaren Text).

42
Arjan Tijms

Neben 

  • code-Wiederverwendung,
  • trennung von Bedenken, 
  • weniger Kopplung zwischen den Schichten

bereits von @bakoyaro und @arjan erwähnt

ich denke, dass MVC besser als 3-Tier ist, wenn es mit dem Muster "convention over configuration" kombiniert wird. (d. h. "Ruby on Rails" oder Microsofts "MVC for asp.net").

Meiner Meinung nach führt diese Kombination zu bessere und einfachere Codewartung.

Zunächst macht es das Lernen des mvc-Rahmens etwas schwieriger, da Sie die Konventionen lernen müssen (a la Controller gehen in den Controller-Ordner und müssen xxxxxcontroller heißen)

Aber nachdem Sie die Konventionen gelernt haben, ist es einfacher, Ihren eigenen und fremden Code zu pflegen. 

6
k3b

Vergessen Sie nicht, die Anwendungsgeschwindigkeit zu erhöhen, indem Sie zu MVC wechseln. Der größte Vorteil liegt in der einfachen Wiederverwendung von Code. Wenn Sie zu MVC wechseln, gibt es keine Abhängigkeiten von der Darstellung Ihrer Daten oder der Speicherung der tatsächlichen Daten. 

Sie könnten beispielsweise ein Servlet schreiben, das eines Tages .jsp-Seiten als Präsentationsschicht bereitstellt, und am nächsten Tag einen Webservice als weitere Präsentationsschicht in Ihr vorhandenes Model und Controller schreiben. Wie klug, wenn Sie Ihr DBMS wechseln wollen oder müssen. Da der Zugriff auf das Modell völlig unabhängig von allem anderen ist, müssen Sie lediglich Ihre Datenzugriffsobjekte neu schreiben, um die Daten auf eine Weise zurückzugeben, die Ihr Controller verarbeiten kann.

Durch die Unterteilung der Bedenken in drei verschiedene Teile erleichtern Sie auch das Testen von Einheiten. Ihre Präsentationsschicht kann ohne Modell oder Controller getestet werden und umgekehrt. 

Nebenbei bemerkt hatte ich oft das Gefühl, dass die Abkürzung für MVC ungenau war. Wann immer ich es sehe, denke ich daran wie View-> Controller-> Model . Die Präsentationsschicht wird niemals DAO-Code enthalten, und das Modell wird niemals Präsentationslogik enthalten. Der Controller muss als Vermittler fungieren.

2
bakoyaro

Bei der dreistufigen Trennung von Präsentation und Geschäfts- und Datenzugriff handelt es sich bei MVC um ein Präsentationsschichtmuster, das Modell (Daten) von Ansicht (Bildschirm) und Controller (Eingabe) weiter trennt.

Es gibt keine MVC-Option für 3-Tier/3-Layer. Verwenden Sie beide.

0
SuperGirl