model-view-controller - unterschied - mvvm vs mvc




Verwenden Sie clientseitige MVC/MVVM-Muster mit serverseitigem MVC-Muster (4)

Die Tatsache, dass Sie ein MVVM-Modell in ein bereits implementiertes MVC-Framework integrieren, ist ebenfalls eine großartige Sache. Vor kurzem haben wir einigen neuen Projektseiten einen Knockout hinzugefügt, der in ein bereits veraltetes MVC-Framework passt (alte Seiten, nicht das Framework selbst).

Ich denke, MVVM ist fantastisch, da die obige Antwort besagt, dass es eine außergewöhnliche Benutzererfahrung mit extrem kurzen Antwortzeiten bietet. Sie können Ihre Bestätigungsaufrufe im Hintergrund verstecken, ohne sie zu verlangsamen und es ist intuitiv.

Der Schmerz ist jedoch, dass es sehr schwierig ist, Unit-Test und Sie können einige sehr große Javascript-Dateien erhalten, auch die zusätzliche Codierung, die wir tun mussten, da unsere Legacy-Systeme noch auf IE6 laufen, ist lächerlich.

Aber MVVM und MVC müssen nicht ausschließlich dort verwendet werden, wir verwenden beide. Aber 3 Validierungsebenen sind etwas, was mich immer noch nervt.

In Anbetracht der beliebtesten Client-seitigen MVC / MVVM-Muster (wie Knockout.js , Angular.js , Ember.js und andere) habe ich einen großen Zweifel:

Betrachtet man auch die Redundanz der Modellierung auf beiden Seiten, was sind die Vor- und Nachteile, diese clientseitigen Muster mit serverseitigen MVC-Mustern zu verwenden?


Ich hatte Probleme damit, diese Frage zu beantworten ... hoffentlich hilft das, auch wenn es sich um eine Runde handelt.

Während einige der Vorteile / Nachteile bereits erwähnt wurden, denke ich, ist der beste Überblick in dieser Antwort .

Der größte Vorteil der clientseitigen Logik ist für mich der umfassende UI-Aspekt.

Aber der Schlüssel Ihrer Frage scheint "Modellredundanz" zu sein (ich würde es als duplizierte Logik bezeichnen oder zumindest Potenzial für doppelte Logik haben). Meiner Meinung nach ist das ein Problem, das unabhängig von den Vor- / Nachteilen des vorherigen Links bestehen kann.

Zuallererst denke ich, dass die Entscheidung, ob ein clientseitiges Framework verwendet werden soll oder nicht, basierend auf den gut dokumentierten Vor- und Nachteilen getroffen werden sollte. Sobald diese Entscheidung getroffen ist, können die damit verbundenen Probleme gelöst werden.

Nehmen wir an, Sie verwenden eine Art serverseitiges Framework / Plattform sowie ein clientseitiges Framework, um ein wenig UI-Interaktivität bereitzustellen. Jetzt gibt es ein Problem mit der Modelllogik: auf dem Client, Server oder beidem.

Eine Möglichkeit, das Problem zu lösen, besteht darin, Ihre Modelllogik nur auf dem Client oder dem Server zu definieren. Dann haben Sie keine Code-Duplizierung, aber es betrifft einige der höheren Pros / Nachteile.

Wenn Ihre Modelllogik beispielsweise zu 100% serverseitig ist, verlieren Sie einen Teil des interaktiven Teils der Benutzeroberfläche. Oder Sie werfen das Modell ständig zum / vom Server, der ein paar Nachteile haben wird.

Wenn Ihre Modelllogik zu 100% clientseitig ist, können Leistungsprobleme auftreten, abhängig von der Größe Ihrer Ansicht / Ihres Modells. Dies ist einer der Gründe, warum Twitter zu einem serverseitigen Verarbeitungsmodell übergeht.

Dann gibt es "beide" ... Modelllogik existiert sowohl im Client als auch im Server. Ich denke, das ist die beste Lösung, solange keine Logik dupliziert wird .

Auf einer Einkaufskorbseite können Sie beispielsweise die Kosten einer Bestellung auf der Grundlage des Preises eines Produkts und eines vom Benutzer änderbaren Betrags neu berechnen. Ich denke, diese Logik sollte nur auf dem Client existieren. Andere Modelleigenschaften, die sich nach dem Laden nicht ändern, werden wahrscheinlich auf dem Server gut gehostet.

Es gibt hier viel Grauzone ... Ich habe Mühe, alle Eier in einen Korb zu legen. Wählen Sie beispielsweise ein clientseitiges Framework, erstellen Sie eine Menge clientseitige Logik und dann [hypothetisch] Probleme mit der Leistung, der Browserunterstützung oder etwas ähnlichem. Jetzt möchten Sie vielleicht eine oder zwei Seiten für die Leistung optimieren (z. B. serverseitig verschieben, a la Twitter). Aber ich denke, dass es schlau ist, wie Sie Ihren Code strukturieren, um dieses Problem zu verringern. Wenn Ihr Code wartbar und sauber ist, wird das Verschieben von Logik von Client zu Server nicht schwierig sein.


Der Vorteil besteht darin, dass die clientseitigen Muster auf dem Client anwendbar sind, auf dem der Server keine direkte Reichweite hat. Wenn Sie eine umfangreiche, interaktive HTML-Benutzeroberfläche erstellen, verwenden Sie die Client-seitige MVVM. Die serverseitige MVC kann in diesem Fall immer noch relevant sein, um dem Client entsprechende Inhalte zu liefern. Beispielsweise ist die ASP.NET-WebAPI ein Framework zum Erstellen von HTTP-APIs, die eine ähnliche Controller-Architektur wie das ASP.NET MVC-Framework aufweist. Die mit diesem Framework implementierte API kann vom clientseitigen Code aufgerufen werden, was MVC auf der Serverseite und MVVM auf der Clientseite zur Folge hat. Normalerweise, wenn MVC-Server-Seite und MVVM-Client-Seite verwendet werden, sind die Verantwortlichkeiten der jeweiligen Seiten sehr unterschiedlich und somit gibt es keine Redundanz.


  • Vorteile
    • Das kann rocken.
  • Vorteile
    • Sie können es schrauben.

Ernst. Wenn Sie einen Teil der Frontend-Logik in den Browser übertragen, kann dies die Anwendungsentwicklung verbessern, weshalb Sie auf der Serverseite eine striktere Datenverarbeitung beibehalten.

Dies ist im Grunde eine Schicht. Zwei Schichten, die eine oben, spricht mit der unteren und umgekehrt:

[client] <--> [server]

Normalerweise tauschen Sie Wertobjekte in einem leichtgewichtigen Serialisierungsformat wie Json zwischen den beiden aus.

Dies kann recht gut zuordnen, was Benutzer in einer nützlichen Struktur erwarten, während Domänenobjekte auf der Serverseite nicht so detailliert sein können.

Allerdings wird die wirkliche Macht sein, wenn die Server-Seite an einem bestimmten Punkt nicht in Javascript geschrieben ist, weil ich denke, dass Sie dort keine Domain-Objekte erstellen können. Betrachten Sie Scala (oder etwas Ähnliches ausdrucksvoll), wenn Sie auf dieses Problem stoßen.