Warum MVVM verwenden?

Das Implementieren von Mustern und das Befolgen von Best Practices sind oft sinnlose Verfolgungen, aber Sie werden zu einem Bekehrten, wenn Ihr Chef Sie Monate später bittet, ein Feature hinzuzufügen oder zu optimieren. Mit MVVM (und Mustern im Allgemeinen) können Sie tatsächlich Ihrem eigenen Code folgen und die Anforderung innerhalb weniger Stunden oder Tage erfüllen, im schlimmsten Fall statt Wochen oder Monaten. (Diese Änderung wird wahrscheinlich nur aus wenigen Zeilen Code bestehen, anstatt Wochen damit zu verbringen, herauszufinden, wie Sie das getan haben, was Sie zuerst getan haben, bevor Sie überhaupt versucht haben, neue Funktionen hinzuzufügen.

Follow-up: Muster und bewährte Vorgehensweisen verlangsamen die anfängliche Entwicklung tatsächlich und das ist oft ein schwerer Verkauf für das Management und das Engineering. Die Amortisation (ROI in Business-Begriffen) beruht auf gut strukturiertem Code, der tatsächlich wartbar, skalierbar und erweiterbar ist.

Wenn Sie beispielsweise MVVM ordnungsgemäß befolgen, sollten Sie in der Lage sein, sehr drastische Änderungen an der Anzeigelogik vorzunehmen, z. B. das Auslagern einer gesamten Ansicht, ohne Auswirkungen auf die Daten- und Business-Logik.

Ein Gedanke über die Verwendung von Datensätzen für Ihr Modell : (Ich habe mich auch darauf verliebt.) Datensätze scheinen eine vollkommen gültige Möglichkeit zu sein, um Modelldaten in einer Anwendung zu bewegen. Das Problem besteht darin, wie Sie die Datenelemente identifizieren. Da Ihre Daten in Zeilen und Spalten gespeichert sind, müssen Sie nach Spaltennamen oder Index suchen und nach einer bestimmten Zeile filtern. Diese Logik bedeutet, dass Sie in Ihrer Anwendung in der Verdrahtungslogik magische Strings und Zahlen verwenden müssen. Die Verwendung eines typisierten Datasets würde einige Probleme beheben, jedoch nicht vollständig. Bei der Verwendung typisierter Datensätze würden Sie sich von MVVM wegbewegen und eine engere Kopplung zwischen der Benutzeroberfläche und der Datenquelle herstellen. 

Es hilft Ihnen bei der Trennung von GUI und Programmlogik. Das Mischen dieser Anwendungen kann dazu führen, dass Anwendungen nur schwer gewartet werden können, insbesondere wenn Ihr Projekt mit der Zeit wächst. 

Von hier :

Warum sollten Sie als Entwickler sogar kümmern uns um das Model-View-ViewModel Muster? Es gibt eine Reihe von Nutzen dieses Muster für beide WPF- und Silverlight-Entwicklung . Bevor Sie fortfahren, fragen Sie sich:

• Müssen Sie ein Projekt für einen Designer freigeben und über die Flexibilität für die Designarbeit und Entwicklungsarbeit zu geschehen fast gleichzeitig?
• Benötigen Sie gründliche Komponententests für Ihre Lösungen?
• Ist es wichtig, dass Sie wiederverwendbare Komponenten sowohl innerhalb als auch .__ haben. projektübergreifend in Ihrer Organisation?
• Möchten Sie mehr Flexibilität beim Ändern Ihrer Benutzeroberfläche ohne andere Logik in der .__ umgestalten müssen. Code-Basis?

Wenn Sie eine dieser Antworten mit "Ja" beantwortet haben Fragen, das sind nur einige der Vorteile, die das MVVM-Modell verwenden kann Bring für dein Projekt mit.

• Es ist einfacher, mit Designern zu arbeiten (nicht mit Programmierern, sondern nur mit Blend)
• Code ist testbar (Unit-Tests)
• Es ist viel einfacher, die Ansicht zu ändern, ohne den Rest des Codes zu beeinträchtigen
• Während Sie die Benutzeroberfläche entwickeln, können Sie ein Modell simulieren und Ihre Schnittstelle entwickeln, ohne einen echten Dienst auszuführen (nur durch Modelldaten). Dann blättern Sie einfach die Flagge und stellen eine Verbindung zum Dienst her. 

Von Josh Smiths Artikel über MVVM :

Zusätzlich zu den WPF-Funktionen (und Silverlight 2) machen MVVM ein natürlicher Weg zur Strukturierung eines Anwendung ist das Muster auch beliebt, weil ViewModel-Klassen .__ sind. Einfacher Gerätetest. Wenn ein Die Interaktionslogik der Anwendung lebt In einer Reihe von ViewModel-Klassen können Sie leicht Code schreiben, der es testet. In einem Sinn, Ansichten und Komponententests sind nur zwei verschiedene Arten von ViewModel Verbraucher. Eine Reihe von Tests für ViewModels einer Anwendung enthält kostenlose und schnelle Regressionstests, was hilft, die Kosten von .__ zu reduzieren. Aufrechterhaltung einer Anwendung im Laufe der Zeit.

Für mich ist das der wichtigste Grund, MVVM einzusetzen. 

Früher hätte ich Steuerelemente, die die Ansicht und das Ansichtsmodell zusammenfügen. Eine Ansicht enthält jedoch im Wesentlichen Maus- und Tastaturereignisse als Eingabe und gezeichnete Pixel als Ausgabe. Wie testest du so etwas? Mit MVVM wird dieses Problem behoben, da die nicht testbare Ansicht vom testfähigen Ansichtsmodell getrennt wird und die Ansichtsebene so dünn wie möglich bleibt.

Ich beschäftige mich noch immer mit dem Muster, aber ich denke, es ist wertvoll. Die größte Herausforderung im Moment ist, dass der Ansatz noch recht neu ist und daher viel Verwirrung herrscht und bestimmte Schlüsselkomponenten des Musters immer noch umständlich zu implementieren sind. Ich habe ein paar Dinge entdeckt, die mir sehr geholfen haben, das Muster sauberer zu machen:

1. Ich nutze den RelayCommand von Josh Smiths MVVM Foundation intensiv. Dadurch wird die Bindung von View an ViewModel über Befehle wesentlich sauberer.

2. Ich verwende AOP, um die Implementierung von INotifyPropertyChanged zu lindern. Ich verwende derzeit Postsharp, obwohl ich glaube, dass es andere Tools gibt, die dies tun können. Wenn ich das nicht entdeckt hätte, hätte ich wahrscheinlich schon aufgegeben, da der Boilerplate-Code zur manuellen Implementierung mich wirklich nervte.

3. Ich musste meine Herangehensweise an die Implementierung der Software ändern. Anstatt über eine Diktatorklasse zu verfügen, die allen Schergen sagt, was zu tun ist, was wiederum ihre Schergen einsetzt, wird meine Software eher eine Angelegenheit von lose gekoppelten Diensten, die sagen:

   • Dies ist, was ich weiß, wie ich es tun soll

   • Dies sind die Dinge, die ich getan haben muss

Wenn Sie anfangen, Ihren Code auf diese Weise zu strukturieren und Tools zu verwenden, mit denen die Abhängigkeiten leicht miteinander verbunden werden können (es gibt eine große Auswahl an IoC-Frameworks, aus denen Sie wählen können), habe ich festgestellt, dass dies die Unbequemlichkeit von MVVM erleichtert Sie können den Boilerplate-Code reduzieren, der mit dem Einfügen der Modelle in ViewModels und dem Auffinden verschiedener View Services (z. B. Anzeigen von Dateidialogen) für Ihre ViewModels verbunden ist.

Es ist eine enorme Investition, um diesen anderen Ansatz zu erlernen, und wie bei jeder größeren Änderung der Implementierung ist die Produktivität beim ersten Einsatz viel geringer. Ich sehe jedoch am Ende des Tunnels etwas Licht und glaube, dass meine Anwendungen sauberer und viel wartbarer sein werden, sobald ich die unordentlichen Details beherrscht.

Um die Frage zu INotifyPropertyChanged über Postsharp zu beantworten, verwende ich einen Aspect basierend auf dem Beispiel hier . Ich habe es ein bisschen für meinen Gebrauch angepasst, aber das gibt Ihnen den Kernpunkt. Damit markiere ich einfach die Klasse [NotifyPropertyChanged] und bei allen öffentlichen Eigenschaften wird das Muster in ihren Setters implementiert (auch wenn es sich um Auto-Property-Setter handelt). Es fühlt sich für mich viel sauberer an, da ich mir keine Sorgen mehr darüber machen muss, ob ich mir die Zeit nehmen möchte, damit die Klasse INotifyPropertyChanged implementiert. Ich kann das Attribut einfach hinzufügen und fertig sein.

Lesen Sie die Einführung in MVVM in diesem Artikel

Im Jahr 2005 stellte John Gossman, derzeit einer der WPF- und Silverlight-Architekten von Microsoft, das Model-View-ViewModel (MVVM) -Muster in seinem Blog vor. MVVM ist mit dem Darstellungsmodell von Fowler identisch, da beide Muster eine Abstraktion einer Ansicht enthalten, die den Zustand und das Verhalten einer Ansicht enthält. Fowler führte Presentation Model als Mittel zur Erstellung einer UI-plattformunabhängigen Abstraktion einer Ansicht ein, während Gossman MVVM als standardisierte Methode zur Nutzung der Kernfunktionen von WPF einführte, um die Erstellung von Benutzeroberflächen zu vereinfachen. In diesem Sinne halte ich MVVM für eine Spezialisierung des allgemeineren PM - Musters, das auf die Plattformen WPF und Silverlight zugeschnitten ist.

..

Im Gegensatz zum Presenter in MVP benötigt ein ViewModel keinen Verweis auf eine Ansicht. Die Ansicht bindet an Eigenschaften in einem ViewModel, das wiederum die in Modellobjekten enthaltenen Daten und andere für die Ansicht spezifische Zustände verfügbar macht. Die Bindungen zwischen view und ViewModel sind einfach zu erstellen, da ein ViewModel-Objekt als DataContext einer Ansicht festgelegt ist. Wenn sich die Eigenschaftswerte im ViewModel ändern, werden diese neuen Werte automatisch über die Datenbindung in die Ansicht übernommen. Wenn der Benutzer in der Ansicht auf eine Schaltfläche klickt, wird ein Befehl im ViewModel ausgeführt, um die angeforderte Aktion auszuführen. Das ViewModel, niemals die View, führt alle an den Modelldaten vorgenommenen Änderungen aus. Die Ansichtsklassen haben keine Ahnung, dass die Modellklassen vorhanden sind, während ViewModel und Modell die Ansicht nicht kennen. Tatsächlich ist das Modell der Tatsache nicht bewusst, dass ViewModel und View vorhanden sind. Dies ist ein sehr locker gekoppeltes Design, das sich in vielerlei Hinsicht auszahlt, wie Sie bald sehen werden.

In diesem Artikel wird auch erläutert, warum diese GUI-Muster verwendet werden:

Es ist unnötig und kontraproduktiv, Designmuster in einem einfachen "Hallo, Welt!" Programm. Jeder kompetente Entwickler kann einige Codezeilen auf einen Blick verstehen. Wenn jedoch die Anzahl der Merkmale in einem Programm zunimmt, nimmt die Anzahl der Codezeilen und der beweglichen Teile entsprechend zu. Die Komplexität eines Systems und die wiederkehrenden Probleme ermutigen die Entwickler schließlich dazu, ihren Code so zu organisieren, dass er einfacher zu verstehen, zu diskutieren, zu erweitern und zu beheben ist. Wir reduzieren das kognitive Chaos eines komplexen Systems, indem wir bekannte Entitäten auf bestimmte Entitäten im Quellcode anwenden. Wir bestimmen den Namen für einen Code, indem wir dessen funktionale Rolle im System berücksichtigen.

Entwickler gestalten ihren Code oft absichtlich nach einem Entwurfsmuster, anstatt die Muster organisch entstehen zu lassen. Bei beiden Ansätzen gibt es nichts zu beanstanden. In diesem Artikel untersuche ich jedoch die Vorteile der expliziten Verwendung von MVVM als Architektur einer WPF-Anwendung. Die Namen bestimmter Klassen enthalten bekannte Begriffe aus dem MVVM-Muster, z. B. enden mit "ViewModel", wenn die Klasse eine Abstraktion einer Ansicht ist. Dieser Ansatz hilft, das zuvor erwähnte kognitive Chaos zu vermeiden. Stattdessen können Sie glücklich in einem Zustand kontrollierten Chaos leben, wie es in den meisten professionellen Softwareentwicklungsprojekten der Fall ist.

MVVM hat viele gute Dinge, aber das Wichtigste ist vielleicht die Möglichkeit, Ihren Code zu testen (Unit-Test der ViewModels).

Die fehlende Verbindung zwischen Ansicht und Ansichtsmodell hilft auch bei der lockeren Kopplung. Es ist sehr einfach, die von Ihnen codierten Komponenten wiederzuverwenden. 

Ich bin damit einverstanden, dass die Verwendung von MVVM den Schultern mehr Gewicht beim Schreiben von Code zuweist, Sehen Sie sich jedoch die helle Seite an, auf der alles isoliert ist. Wenn Sie ein Designer sind, können Sie Ihr Programm entwerfen und andere Programme für Sie und andere erstellen Wenn Sie die Datenbankschicht für Sie verwenden, schauen Sie, in welcher wartungsfähigen Umgebung Sie sich gerade in großen Unternehmensanwendungen befinden werden, wenn Sie MVVM nicht verwenden würden. Dann ist die Wartung fast tödlich .... Ich habe es selbst bei der Entwicklung verwendet ERP jetzt ist die Wartung aufgrund dieses Isolationsniveaus ziemlich einfach

Sie werden auf lange Sicht glücklich sein, wenn Sie ein Muster wie MVVM aus allen Gründen verwenden, die von anderen veröffentlicht wurden. Denken Sie daran, dass Sie nicht den Musteranforderungen Word-for-Word folgen müssen, sondern stellen Sie sicher, dass Sie eine gute Trennung zwischen Ihrem Fenster (Ansicht) und Ihrer Logik (Code-behind) haben.

MVVM ist wirklich übertriebener Code. 

Welche Vorteile bietet die MVVM? 

Es ist nur Trennung von Bedenken nicht mehr. Sie können auch die ViewModel-Logik in den Controller schreiben. Das ViewModel ist nur für eine Konvertierung zuständig (zum Beispiel und ein Objekt in einen String). Durch die Verwendung von MVVM verwenden Sie einen mehr objektorientierten Programmierstil. Durch das Schreiben der Konvertierungslogik in den Controller verwenden Sie einen funktionaleren Programmierstil.

Es kommt also darauf an, mehr Code mit besserer Lesbarkeit oder weniger Code mit großen Controller-Dateien zu haben. Zusammenfassend können Sie nicht sagen, dass Sie MVVM verwenden müssen, weil es besser ist als MVC oder so, es ist nur eine persönliche Präferenz.

Nur um klar zu sein, warum ich einen Controller erwähne: MVVM hat auch irgendwo Controller-Code. Ich habe keine Ahnung, warum es einen breiten Konsens gibt, das C. zu verlassen.

Vorteile von MVVM

1. Reduzierte Komplexität.
2. Isolation von Design und Entwicklung.
3. Abhängigkeitsspritze.
4. Ein großer Vorteil ist, wenn Sie eine gut mit MVVM strukturierte Windows Phone-Anwendung haben und dieselbe für Windows Metro Desktop entwickeln möchten.

Ich hoffe es hilft.