Grundlegende Konzepte von MVVM - was sollte ein ViewModel tun?

Question

Bei dem Versuch, die Konzepte von MVVM zu verstehen, habe ich bereits mehrere Blogs gelesen und mir ein paar Projekte angesehen.

Soviel ich weiß, ist ein Siehe ist dumm, es weiß nur, wie es etwas, das ihm übergeben wird, darstellen soll.

Modelle sind nur die reinen Daten, und ein ViewModel ist etwas, das wie ein Polster zwischen den beiden fungiert, das Informationen von der Modell und leiten ihn an die Siehe und die Siehe sollte wissen, wie man sie präsentiert. Oder andersherum, wenn die Informationen in der Siehe ändert, sollte es die Änderung an den Modell .

Aber ich habe immer noch keine Ahnung, wie ich das Konzept anwenden soll. Kann mir jemand ein ganz einfaches Szenario erklären, damit ich das Konzept begreifen kann? Ich habe mir bereits mehrere Projekte angeschaut, aber es ergibt immer noch keinen vollständigen Sinn, also wäre es schön, wenn es jemand in einfachem Englisch schreiben könnte.

Answer 1

Ich stelle mir das so vor:

Ansichten sind, wie Sie sagen, dumm. Josh Smith, Autor des bahnbrechenden und oft verlinkten MSDN-Artikel über MVVM, hat gesagt, dass Views "die Kleider sind, die die Daten tragen". Ansichten enthalten eigentlich nie Daten oder manipulieren sie direkt, sie sind nur an Eigenschaften und Befehle Ihrer Viewmodels gebunden.

Modelle sind Objekte, die modellieren den Bereich Ihrer Anwendung wie bei Geschäftsobjekten. Ist Ihre Anwendung ein Musikgeschäft? Vielleicht sind Ihre Modellobjekte Künstler, Alben und Songs. Handelt es sich bei Ihrer Anwendung um einen Organigrammbrowser? Vielleicht sind Ihre Modellobjekte Manager und Mitarbeiter. Diese Modellobjekte haben nichts mit der visuellen Darstellung zu tun und stehen nicht einmal in direktem Zusammenhang mit der Anwendung, in die sie eingefügt werden - Ihre Modellobjekte sollten als eine Familie von Objekten, die eine Art von Domäne repräsentieren, für sich allein stehen. Die Modellschicht enthält auch typischerweise Dinge wie Service Accessors.

Dies bringt uns zu den Ansichtsmodellen. Was sind diese? Sie sind Objekte, die modellieren eine GUI-Anwendung Das heißt, sie stellen Daten und Funktionen zur Verfügung, die von den Ansichten genutzt werden können. Sie definieren die Struktur und das Verhalten der eigentlichen Anwendung, die Sie erstellen. Für die Modellobjekte ist die Domäne die von Ihnen gewählte Domäne (Musikgeschäft, Organigramm-Browser usw.), für die Ansichtsmodelle ist die Domäne jedoch eine grafische Anwendung. Ihre Viewmodels kapseln das Verhalten und die Daten von allem, was Ihre Anwendung tut. Sie stellen Objekte und Listen als Eigenschaften zur Verfügung, ebenso wie Dinge wie Befehle. Ein Befehl ist nur ein Verhalten (im einfachsten Fall ein Methodenaufruf), das in ein Objekt verpackt ist, das es mit sich führt - dieser Gedanke ist wichtig, weil Ansichten durch Datenbindung gesteuert werden, die visuelle Steuerelemente an Objekte bindet. In MVVM geben Sie einer Schaltfläche keine Click-Handler-Methode, sondern binden sie an ein Command-Objekt (das von einer Eigenschaft in einem Viewmodel bereitgestellt wird), das die Funktionalität enthält, die Sie ausführen möchten, wenn Sie auf die Schaltfläche klicken.

Für mich waren die folgenden Punkte am verwirrendsten:

• Obwohl es sich bei den Viewmodels um Modelle einer grafischen Anwendung handelt, verweisen sie nicht direkt auf visuelle Konzepte oder verwenden diese. Sie wollen zum Beispiel keine Verweise auf Windows-Steuerelemente in Ihren ViewModels - diese Dinge gehören in die Ansicht. ViewModels stellen einfach Daten und Verhaltensweisen für Steuerelemente oder andere Objekte zur Verfügung, die mit ihnen verbunden werden. Haben Sie zum Beispiel eine Ansicht mit einer ListBox darin? Ihr ViewModel wird mit ziemlicher Sicherheit eine Art von Sammlung enthalten. Verfügt Ihr View über Schaltflächen? Ihr Viewmodel wird mit ziemlicher Sicherheit einige Befehle enthalten.
• Es gibt einige Arten von Objekten, die als "Ansichtsmodelle" betrachtet werden können. Die einfachste Art von Viewmodel ist eines, das direkt ein Steuerelement oder einen Bildschirm in einer 1:1-Beziehung darstellt, wie z. B. "Bildschirm XYZ hat ein Textfeld, ein Listenfeld und drei Schaltflächen, also braucht das Viewmodel eine Zeichenkette, eine Sammlung und drei Befehle." Eine andere Art von Objekten, die in die Viewmodel-Schicht passt, ist ein Wrapper um ein Modellobjekt, der ihm Verhalten verleiht und es für eine Ansicht besser nutzbar macht - hier kommen Sie zu den Konzepten der "dicken" und "dünnen" Viewmodel-Schichten. Eine "dünne" Viewmodel-Schicht besteht aus einer Reihe von Viewmodels, die Ihre Modellobjekte direkt den Views zur Verfügung stellen, d.h. die Views binden sich direkt an Eigenschaften der Modellobjekte. Dies kann z. B. für einfache, schreibgeschützte Ansichten funktionieren, aber was ist, wenn Sie jedem Objekt ein Verhalten zuordnen möchten? Das wollen Sie nicht im Modell haben, weil das Modell nicht mit der Anwendung, sondern nur mit Ihrer Domäne verbunden ist. Sie können es in einem Objekt unterbringen, das Ihr Modellobjekt umhüllt und bindungsfreundlichere Daten und Verhaltensweisen bereitstellt. Dieses Wrapper-Objekt wird auch als Viewmodel bezeichnet und führt zu einer "dickeren" Viewmodel-Schicht, bei der Ihre Views nie direkt an eine Modellklasse gebunden sind. Sammlungen enthalten Viewmodels, die Modelle umhüllen, anstatt nur Modelle selbst zu enthalten.

Der Kaninchenbau geht noch tiefer - es gibt viele Idiome wie ValueConverters, die MVVM am Laufen halten, und es gibt eine Menge anzuwenden, wenn man anfängt, über Dinge wie Blendability, Testen und wie man Daten in der App weitergibt und sicherstellt, dass jedes Viewmodel Zugriff auf das Verhalten hat, das es braucht (hier kommt Dependency Injection ins Spiel), aber hoffentlich ist das oben Gesagte ein guter Anfang. Das Wichtigste ist, dass Sie Ihre Visuals, Ihre Domäne und die Struktur und das Verhalten Ihrer eigentlichen Anwendung als drei verschiedene Dinge betrachten.

Answer 2

Verwendung von diesen unglaublich hilfreichen Artikel als Quelle, hier ist eine Zusammenfassung für Siehe , ViewModel y Modell .

---

Ansicht:

• Die Ansicht ist ein visuelles Element, z. B. ein Fenster, eine Seite, ein Benutzersteuerelement oder eine Datenvorlage. Die Ansicht definiert die in der Ansicht enthaltenen Steuerelemente und deren visuelles Layout und Styling.

• Die Ansicht referenziert das Ansichtsmodell über ihre DataContext Eigentum. Die Steuerelemente in der Ansicht sind datengebunden an die Eigenschaften und Befehle des Ansichtsmodells.

• Die Ansicht kann das Datenbindungsverhalten zwischen der Ansicht und dem Ansichtsmodell anpassen. Beispielsweise kann die Ansicht Wertkonverter verwenden, um die in der Benutzeroberfläche anzuzeigenden Daten zu formatieren, oder sie kann Validierungsregeln verwenden, um dem Benutzer zusätzliche Eingabedatenvalidierung zu bieten.

• Die Ansicht definiert und verwaltet das visuelle Verhalten der Benutzeroberfläche, wie z. B. Animationen oder Übergänge, die durch eine Zustandsänderung im Ansichtsmodell oder durch die Interaktion des Benutzers mit der Benutzeroberfläche ausgelöst werden können.

• Der Code-Behind der View kann UI-Logik definieren, um visuelles Verhalten zu implementieren, das sich nur schwer in XAML ausdrücken lässt oder direkte Verweise auf die in der View definierten spezifischen UI-Steuerelemente erfordert.

HINWEIS:
Da das View-Modell keine expliziten Kenntnisse über die spezifischen visuellen Elemente in der View haben sollte, sollte der Code zur programmatischen Bearbeitung der visuellen Elemente innerhalb der View im Code-Behind der View liegen oder in einem Verhalten gekapselt sein.

---

Ansicht Modell:

• Das Ansichtsmodell ist eine nicht visuelle Klasse und leitet sich nicht von einer WPF- oder Silverlight-Basisklasse ab. Es kapselt die Präsentationslogik, die zur Unterstützung eines Anwendungsfalls oder einer Benutzeraufgabe in der Anwendung erforderlich ist. Das Ansichtsmodell ist unabhängig von der Ansicht und dem Modell testbar.

• Das Ansichtsmodell verweist normalerweise nicht direkt auf die Ansicht. Es implementiert Eigenschaften und Befehle, an die die Ansicht Daten binden kann. Es benachrichtigt die Ansicht über alle Zustandsänderungen mittels Änderungsbenachrichtigungsereignissen über die INotifyPropertyChanged y INotifyCollectionChanged Schnittstellen.

• Das Ansichtsmodell koordiniert die Interaktion der Ansicht mit dem Modell. Es kann Daten konvertieren oder manipulieren, so dass sie von der Ansicht problemlos genutzt werden können, und kann zusätzliche Eigenschaften implementieren, die im Modell nicht vorhanden sind. Es kann auch die Validierung von Daten über die IDataErrorInfo o INotifyDataErrorInfo Schnittstellen.

• Das Ansichtsmodell kann logische Zustände definieren, die die Ansicht für den Benutzer visuell darstellen kann.

HINWEIS:
Alles, was für das logische Verhalten der Anwendung wichtig ist, sollte in das Ansichtsmodell aufgenommen werden. Code zum Abrufen oder Bearbeiten von Datenelementen, die in der Ansicht durch Datenbindung angezeigt werden sollen, sollte sich im Ansichtsmodell befinden.

---

Modell:

• Modellklassen sind nicht-visuelle Klassen, die die Daten und die Geschäftslogik der Anwendung kapseln. Sie sind für die Verwaltung der Daten der Anwendung und für die Sicherstellung ihrer Konsistenz und Gültigkeit verantwortlich, indem sie die erforderlichen Geschäftsregeln und die Logik zur Datenvalidierung kapseln.

• Die Modellklassen verweisen nicht direkt auf die View- oder Viewmodellklassen und sind nicht davon abhängig, wie diese implementiert werden.

• Die Modellklassen bieten typischerweise Benachrichtigungsereignisse für Eigenschafts- und Auflistungsänderungen über die INotifyPropertyChanged y INotifyCollectionChanged Schnittstellen. Dadurch können sie leicht in der Ansicht datengebunden werden. Modellklassen, die Sammlungen von Objekten darstellen, leiten sich typischerweise von der ObservableCollection<T> Klasse.

• Die Modellklassen bieten in der Regel Datenvalidierung und Fehlerberichterstattung entweder durch die IDataErrorInfo o INotifyDataErrorInfo Schnittstellen.

• Die Modellklassen werden in der Regel in Verbindung mit einem Dienst oder einem Repository verwendet, das den Datenzugriff und das Caching kapselt.

Answer 3

Ich habe dies in so "einfachem Englisch" geschrieben, wie ich es mir vorstellen kann in diese Serie über MVVM . Im Besonderen, dieses Diagramm ist wahrscheinlich die einfachste und kürzeste Erklärung.

Davon abgesehen, ist das "Modell" im Grunde Ihre Daten oder Geschäftsregeln. Es sollte wirklich nicht wissen, wie oder wo es verwendet wird, und vor allem nicht, welche Technologie es verwenden wird. Das "Modell" ist der Kern der Anwendung - und es sollte sich keine Gedanken darüber machen müssen, ob die Anwendung WPF, Silverlight, Windows Forms, ASP.NET usw. ist - es ist einfach "es selbst" in reiner Form.

Die "View" ist der Teil, der völlig technologiespezifisch ist. Bei MVVM sollte die View idealerweise zu fast 100 % aus XAML bestehen, da dies einen enormen Gewinn an Flexibilität bedeutet.

Es muss jedoch etwas vorhanden sein, das die Informationen aus dem Modell in eine Form übersetzt, in der sie von der jeweiligen Technologie genutzt werden können - hier kommt das ViewModel ins Spiel. So werden beispielsweise die Modellklassen oft in ein "ViewModel" für diese spezifischen Daten "verpackt", das Befehle (für die Ausführung der Logik) enthält und Folgendes implementiert INotifyPropertyChanged (zur Unterstützung der Datenbindung), usw. Das war's - die Brücke, die das Modell für die Ansicht nutzbar macht.

Answer 4

Eine gute Einführung in MVVM finden Sie in Jason Dolingers Video aquí . Ich habe das Video eine ganze Weile mit mir herumgetragen, als ich anfing, es ist wirklich nützlich.

Answer 5

Der Aufbau eines ViewModels, das eine konsistente Fassade über das zugrunde liegende Model darstellt, kann viel komplexer sein, als es aussieht. Diese Artikel über die Erstellung von ViewModel-Objekten zeigt, wie man ein ViewModel erstellt, und veranschaulicht einige der Probleme, auf die Sie wahrscheinlich stoßen werden - zusammen mit den scheinbar vernünftigen Lösungen. Als ich es las, fehlte der Abschnitt über den Umgang mit Sammlungen, aber es hat immer noch einige interessante Punkte.