1424 Stimmen

Was ist der Unterschied zwischen MVC und MVVM?

Gibt es einen Unterschied zwischen dem Standardmuster "Model-View-Controller" und dem Model/View/ViewModel-Muster von Microsoft?

78 Stimmen

Beachten Sie, dass MVVM zwar von Microsoft geprägt wurde, aber auch viele Entwickler und Projekte außerhalb von Microsoft begonnen haben, dieses Muster zu übernehmen. Dieser Kommentar wurde Ihnen von der Abteilung "spite-the-MS-haters" zur Verfügung gestellt.

3 Stimmen

Nachdem ich lange Zeit mit MVVM gearbeitet habe, war meine erste Begegnung mit MVC frustrierend, bis ich lernte, dass ich ViewModels mit Hilfe von Bindungstechniken, die in MVVM zu finden sind, hin und her an den Browser übergeben kann. Aber wie Joel oben sagte, ist der einzige Weg, um den Zustand vom Browser zurückzubekommen, das Posten der Änderungen in einem Formular (das Name/Wert-Paare verwendet). Wenn Sie diesen Punkt nicht gut verstehen. Sie werden eine harte Zeit in MVC haben. Betrachten Sie den Controller einfach als einen Dependency Injector für die View und Sie sind bereit.

6 Stimmen

Eine solche Frage zu hochrangigen [Entwurfsmustern]. Ich würde gerne die Verwendung von Diagrammen in den Antworten vorschlagen.

9voto

ScottyBlades Punkte 9468

MVVM

  1. Ansicht ViewModel Model
  • Die Ansicht hat einen Verweis auf das ViewModel, aber nicht umgekehrt.
  • Das ViewModel hat einen Verweis auf das Model, aber nicht andersherum.
  • Die Ansicht hat keinen Verweis auf das Modell und umgekehrt.
  1. Wenn Sie einen Controller verwenden, kann dieser einen Verweis auf Ansichten y AnsichtenModelle obwohl ein Controller nicht immer notwendig ist, wie in SwiftUI .
  2. Daten Bindung : Wir erstellen Listener für ViewModel-Eigenschaften, so dass Daten von der Ansicht zum Modell über das Ansichtsmodell fließen können. Während die Referenzen in eine Richtung gehen: View ViewModel Model, müssen die Daten fließen: Ansicht AnsichtModell Modell. Es ist klar, wie die Ansicht Daten aus dem Modell erhält, indem sie ihre eigenen Eigenschaften liest. Data Binding ist die Art und Weise, wie Ereignisse innerhalb der Ansicht erkannt und an das Modell zurückgegeben werden.

    class CustomView: UIView { var viewModel = MyViewModel { didSet { self.color = viewModel.viewColor } }

    convenience init(viewModel: MyViewModel) { self.viewModel = viewModel } }

    struct MyViewModel { var viewColor: UIColor { didSet { colorChanged?() // This is where the binding magic happens. } }

    var colorChanged: ((UIColor) -> Void)? }

    class MyViewController: UIViewController {

    let myViewModel = MyViewModel(viewColor: .green) let customView: CustomView!

    override func viewDidLoad() { super.viewDidLoad()

      // This is where the binder is assigned.
      myViewModel.colorChanged = { [weak self] color in 
        print("wow the color changed")
      }
      customView = CustomView(viewModel: myViewModel)
      self.view = customView

    } }

Unterschiede im Aufbau

  1. Die Geschäftslogik befindet sich bei MVC im Controller und bei MVVM in den ViewModels.
  2. In MVC werden Ereignisse direkt von der View an den Controller übergeben, während in MVVM Ereignisse von der View an das ViewModel an den Controller (falls vorhanden) übergeben werden.

Gemeinsame Merkmale

  1. Sowohl MVVM als auch MVC erlauben es der View nicht, Nachrichten direkt an das/die Model/s zu senden.
  2. Beide haben Modelle.
  3. Beide haben Ansichten.

Vorteile von MVVM

  1. Da die ViewModels die Geschäftslogik enthalten, sind sie kleinere konkrete Objekte, die sich leicht in Unit-Tests testen lassen. Im Gegensatz dazu befindet sich bei MVC die Geschäftslogik im ViewController. Wie kann man sich darauf verlassen, dass ein Unit-Test eines ViewControllers umfassend sicher ist, ohne alle Methoden und Listener gleichzeitig zu testen? Man kann den Ergebnissen der Unit-Tests nicht ganz trauen.
  2. Da bei MVVM die Geschäftslogik aus dem Controller in atomare ViewModel-Einheiten ausgelagert wird, schrumpft die Größe des ViewControllers, wodurch der ViewController-Code besser lesbar wird.

Vorteile von MVC

  1. Durch die Bereitstellung von Geschäftslogik innerhalb des Controllers wird die Notwendigkeit von Verzweigungen verringert, und daher werden Anweisungen eher im Cache ausgeführt, was leistungsfähiger ist als die Kapselung von Geschäftslogik in ViewModels.
  2. Die Bereitstellung der Geschäftslogik an einer Stelle kann den Entwicklungsprozess für einfache Anwendungen beschleunigen, für die keine Tests erforderlich sind. Ich weiß nicht, wann Tests nicht erforderlich sind.
  3. Die Bereitstellung von Geschäftslogik im ViewController ist für neue Entwickler einfacher zu denken.

3 Stimmen

Beste Erklärung

8voto

daneejela Punkte 10553

Kurz gesagt: In MVC kennt der Controller die (Controls) View, während in MVVM das ViewModel nicht weiß, wer es konsumiert. Das ViewModel stellt seine beobachtbaren Eigenschaften und Aktionen jedem zur Verfügung, der daran interessiert ist, es zu benutzen. Diese Tatsache macht das Testen einfacher, da es innerhalb des ViewModels keinen Verweis auf die Benutzeroberfläche gibt.

7voto

Nun, im Allgemeinen wird MVC in der Web-Entwicklung verwendet und MVVM ist in der WPF/Silverlight-Entwicklung am beliebtesten. Doch manchmal die Web-Architecute könnte eine Mischung aus MVC und MVVM haben.

Zum Beispiel: Sie könnten verwenden knockout.js und in diesem Fall werden Sie MVVM auf Ihrer Client-Seite haben. Und die Serverseite Ihrer MVC kann sich auch ändern. In komplexen Anwendungen verwendet niemand das reine Model. Es könnte sinnvoll sein, ein ViewModel als "Model" von MVC zu verwenden und Ihr echtes Model wird im Grunde ein Teil dieser VM sein. Dies gibt Ihnen eine zusätzliche Abstraktionsschicht.

0 Stimmen

Was in der Web-Entwicklung als "MVC" bezeichnet wird, ist nichts anderes als die Trennung von Anliegen und nicht das echte MVC, das dem Web vorausging.

6voto

Ini Punkte 401

Der Controller wird in MVVM nicht durch ein ViewModel ersetzt, denn das ViewModel hat eine ganz andere Funktionalität als ein Controller. Sie brauchen immer noch einen Controller, denn ohne einen Controller werden Ihr Model, ViewModel und View nicht viel tun... In MVVM haben Sie auch einen Controller, der Name MVVM ist einfach irreführend.

MVVMC ist meiner bescheidenen Meinung nach die richtige Bezeichnung.

Wie Sie sehen können, ist das ViewModel nur eine Ergänzung zum MVC-Muster. Es verlagert die Konvertierungslogik (z. B. Konvertierung eines Objekts in einen String) vom Controller zum ViewModel.

4voto

der Martin Punkte 51

MVVMC, oder vielleicht MVC+, scheint ein praktikabler Ansatz sowohl für die Unternehmens- als auch für die schnelle Anwendungsentwicklung zu sein. Es ist zwar schön, die Benutzeroberfläche von der Geschäfts- und Interaktionslogik zu trennen, aber das "reine" MVVM-Muster und die meisten verfügbaren Beispiele funktionieren am besten mit einzelnen Ansichten.

Ich weiß nicht, wie es bei Ihnen aussieht, aber die meisten meiner Anwendungen enthalten Seiten und mehrere (wiederverwendbare) Ansichten, so dass die ViewModels bis zu einem gewissen Grad interagieren müssen. Die Seite als Controller zu verwenden, würde den Zweck des MVVM völlig zunichte machen, so dass ein Verzicht auf einen "VM-C"-Ansatz für die zugrunde liegende Logik zu nun ja herausfordernden Konstrukten führen könnte, wenn die Anwendung reift. Selbst in VB-6 haben die meisten von uns wahrscheinlich aufgehört, Geschäftslogik in das Button-Ereignis zu kodieren, und angefangen, Befehle an einen Controller weiterzuleiten, oder? Ich habe mir vor kurzem viele neue Rahmenwerke zu diesem Thema angesehen; mein Favorit ist eindeutig der Magellan-Ansatz (bei codeplex). Viel Spaß beim Kodieren!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X