Warum MVVM verwenden?

Okay, ich habe mich mit MVVM-Mustern befasst und jedes Mal, wenn ich zuvor versucht habe, sie zu untersuchen, habe ich aus mehreren Gründen aufgegeben:

1. Unnötige extra lange Wicklung
2. Keine offensichtlichen Vorteile für Programmierer (keine Designer in meinem Büro. Derzeit bin nur ich bald ein weiterer Programmierer)
3. Nicht viele Ressourcen / Dokumentation bewährter Verfahren! (Oder zumindest schwer zu finden)
4. Ich kann mir kein einziges Szenario vorstellen, in dem dies vorteilhaft ist.

Ich werde es gleich wieder aufgeben und dachte, ich würde fragen, ob jemand die oben genannten Gründe beantwortet.

Ich sehe ehrlich gesagt keinen Vorteil darin, dies für eine Einzel- / Partnercodierung zu verwenden. Auch bei komplexen Projekten mit 10 Fenstern. Für mich ist das DataSet eine ausreichend gute Ansicht und verbindlich wie in der Antwort von Brent auf die folgende Frage

Könnte jemand ein Beispiel dafür zeigen, wo die Verwendung von MVVM-Mustern im Vergleich zu XAML DataBinding Zeit spart.

100% meiner Bindung erfolgt derzeit in XAML. Und deshalb sehe ich den Sinn der VM nicht als zusätzlichen Code dahinter, den ich schreiben und auf den ich mich verlassen muss.

EDIT:
Nachdem ich den Nachmittag damit verbracht hatte, über MVVM zu recherchieren, habe ich endlich etwas gefunden, das mich die wahren Vorteile dieser Antwort erkennen ließ .

Zusammenfassung

• Die Verwendung aller Muster ist situativ und der Vorteil (falls vorhanden) liegt immer in der verringerten Komplexität.
• MVVM zeigt uns, wie Sie Verantwortlichkeiten auf Klassen in einer GUI-Anwendung verteilen.
• ViewModel projiziert die Daten aus dem Modell in ein Format, das zur Ansicht passt.
• Für triviale Projekte ist MVVM nicht erforderlich. Es reicht aus, nur die Ansicht zu verwenden.
• Bei einfachen Projekten ist die Aufteilung von ViewModel / Modell möglicherweise nicht erforderlich, und die Verwendung eines Modells und einer Ansicht ist ausreichend.
• Model und ViewModel müssen nicht von Anfang an vorhanden sein und können bei Bedarf eingeführt werden.

Wann man Muster verwendet und wann man sie vermeidet

Für eine ausreichend einfache Anwendung ist jedes Entwurfsmuster übertrieben. Angenommen, Sie schreiben eine GUI-Anwendung, die eine einzelne Schaltfläche anzeigt, die beim Drücken "Hallo Welt" anzeigt. In diesem Fall erhöhen Entwurfsmuster wie MVC, MVP und MVVM die Komplexität erheblich, ohne jedoch einen Mehrwert zu bieten.

Im Allgemeinen ist es immer eine schlechte Entscheidung, ein Designmuster einzuführen, nur weil es etwas passt. Entwurfsmuster sollten verwendet werden, um die Komplexität zu reduzieren, entweder indem die Gesamtkomplexität direkt reduziert wird oder indem ungewohnte Komplexität durch vertraute Komplexität ersetzt wird. Wenn das Entwurfsmuster die Komplexität auf keine dieser beiden Arten reduzieren kann, verwenden Sie es nicht.

Um die vertraute und unbekannte Komplexität zu erklären, nehmen Sie die folgenden 2 Zeichenfolgen:

• "D. € | Ré% dfà? C"
• "CorrectHorseBatteryStaple"

Während die zweite Zeichenfolge doppelt so lang ist wie die erste, ist sie leichter zu lesen, schneller zu schreiben und leichter zu merken als die erste Folge, weil sie vertrauter ist. Gleiches gilt für bekannte Muster im Code.

Dieses Problem gewinnt eine andere Dimension, wenn Sie bedenken, dass die Vertrautheit vom Leser abhängt. Einige Leser werden feststellen, dass "3.14159265358979323846264338327950" leichter zu merken ist als eines der oben genannten Passwörter. Einige werden nicht. Wenn Sie also eine MVVM-Variante verwenden möchten, versuchen Sie, eine zu verwenden, die die häufigste Form in der von Ihnen verwendeten Sprache und dem verwendeten Framework widerspiegelt.

MVVM

Lassen Sie uns anhand eines Beispiels auf das Thema MVVM eingehen. MVVM zeigt uns, wie Verantwortlichkeiten zwischen Klassen in einer GUI-Anwendung (oder zwischen Ebenen - dazu später mehr) verteilt werden, mit dem Ziel, eine kleine Anzahl von Klassen zu haben und gleichzeitig die Anzahl der Verantwortlichkeiten pro Klasse klein und klar zu halten.

'Richtig' MVVM setzt zumindest eine mäßig komplexe Anwendung voraus, die sich mit Daten befasst, die von "irgendwo" stammen. Es kann die Daten aus einer Datenbank, einer Datei, einem Webdienst oder aus einer Vielzahl anderer Quellen abrufen.

Beispiel

In unserem Beispiel haben wir 2 Klassen Viewund Model, aber nein ViewModel. Der ModelWraps eine CSV-Datei, die er beim Start liest und beim Herunterfahren der Anwendung speichert, mit allen Änderungen, die der Benutzer an den Daten vorgenommen hat. Dies Viewist eine Window-Klasse, die die Daten aus Modeleiner Tabelle anzeigt und es dem Benutzer ermöglicht, die Daten zu bearbeiten. Der CSV-Inhalt könnte ungefähr so ​​aussehen:

ID, Name, Price
1, Stick, 5$
2, Big Box, 10$
3, Wheel, 20$
4, Bottle, 3$

Neue Anforderungen: Preis in Euro anzeigen

Jetzt werden wir gebeten, eine Änderung an unserer Anwendung vorzunehmen. Die Daten bestehen aus einem zweidimensionalen Raster, das bereits eine "Preisspalte" enthält, die einen Preis in USD enthält. Wir müssen eine neue Spalte hinzufügen, in der die Preise in Euro zusätzlich zu denen in USD angezeigt werden, basierend auf einem vordefinierten Wechselkurs. Das Format der CSV-Datei darf sich nicht ändern, da andere Anwendungen mit derselben Datei arbeiten und diese anderen Anwendungen nicht unter unserer Kontrolle stehen.

Eine mögliche Lösung besteht darin, die neue Spalte einfach zur ModelKlasse hinzuzufügen . Dies ist nicht die beste Lösung, da Modelhierdurch alle Daten gespeichert werden, die der CSV zur Verfügung gestellt werden - und wir keine neue Euro-Preisspalte in der CSV wünschen. Die Änderung an Modelwäre also nicht trivial, und es wäre auch schwieriger zu beschreiben, was die Model-Klasse tut, was ein Code-Geruch ist .

Wir könnten die Änderung auch in der vornehmen View, aber unsere aktuelle Anwendung verwendet Datenbindung, um die Daten direkt anzuzeigen, wie von unserer ModelKlasse bereitgestellt . Da unser GUI-Framework es uns nicht erlaubt, eine zusätzliche berechnete Spalte in eine Tabelle einzufügen, wenn die Tabelle an eine Datenquelle gebunden ist, müssten wir eine wesentliche Änderung Viewan vornehmen, damit dies funktioniert, was die ViewKomplexität erheblich erhöht .

Einführung in das ViewModel

Es gibt keine ViewModelin der Anwendung, da Modeldie Daten bis jetzt genau so dargestellt werden, wie es die CSV benötigt, und auch so, wie sie Viewbenötigt werden. Ein ViewModelZwischenraum zu haben, wäre ohne Zweck komplexer geworden. Aber jetzt, da die ModelDaten nicht mehr so ​​dargestellt werden, wie sie Viewbenötigt werden, schreiben wir eine ViewModel. Das ViewModelprojiziert die Daten der Modelso, dass die Vieweinfach sein können. Zuvor hat die ViewKlasse die Klasse abonniert Model. Jetzt ViewModelabonniert die neue Klasse die ModelKlasse und stellt die ModelDaten der Klasse der View- zur Verfügung. In einer zusätzlichen Spalte wird der Preis in Euro angezeigt. Das Viewweiß der nicht mehrModelJetzt kennt es nur noch das ViewModel, was vom Standpunkt des ViewAussehens aus genauso aussieht Modelwie zuvor - außer dass die exponierten Daten eine neue schreibgeschützte Spalte enthalten.

Neue Anforderungen: andere Art, die Daten zu formatieren

Die nächste Kundenanforderung lautet, dass wir die Daten nicht als Zeilen in einer Tabelle anzeigen sollen, sondern stattdessen die Informationen jedes Elements (auch als Zeile bezeichnet) als Karte / Box anzeigen und 20 Boxen in einem 4x5-Raster auf dem Bildschirm anzeigen sollen, wobei 20 angezeigt werden Boxen auf einmal. Weil wir die Logik des ViewEinfachen beibehalten haben , ersetzen wir das Einfache Viewvollständig durch eine neue Klasse, die den Wünschen des Kunden entspricht. Natürlich gibt es einen anderen Kunden, der den alten bevorzugt View, also müssen wir jetzt beide unterstützen. Da die gesamte gängige Geschäftslogik bereits vorhanden ViewModelist, ist dies kein großes Problem. Wir können dieses Problem lösen, indem wir die View-Klasse in umbenennen TableViewund eine neue schreibenCardViewKlasse, die die Daten in einem Kartenformat anzeigt. Wir müssen auch einen Klebercode schreiben, der möglicherweise ein Oneliner in der Startfunktion ist.

Neue Anforderungen: dynamischer Wechselkurs

Die nächste Kundenanfrage ist, dass wir den Wechselkurs aus dem Internet beziehen, anstatt einen vordefinierten Wechselkurs zu verwenden. Dies ist der Punkt, an dem wir meine frühere Aussage über "Ebenen" erneut betrachten. Wir ändern unsere ModelKlasse nicht, um einen Wechselkurs bereitzustellen. Stattdessen schreiben (oder finden) wir eine völlig unabhängige zusätzliche Klasse, die den Wechselkurs liefert. Diese neue Klasse wird Teil der Modellebene, und wir ViewModelkonsolidieren die Informationen des CSV-Modells und des Wechselkursmodells, die sie dann dem Modell präsentieren View. Für diese Änderung müssen die alte Model-Klasse und die View-Klasse nicht einmal berührt werden. Nun, wir müssen die Model-Klasse in umbenennen CsvModelund rufen die neue Klasse auf ExchangeRateModel.

Wenn wir das ViewModel nicht eingeführt hätten, sondern stattdessen bis jetzt darauf gewartet hätten, wäre der Arbeitsaufwand für die Einführung des ViewModel jetzt höher, da wir sowohl vom als auch vom Viewund zum ModelVerschieben erhebliche Mengen an Funktionen entfernen müssen die Funktionalität in die ViewModel.

Nachwort zu Unit Tests

Der Hauptzweck von MVVM besteht nicht darin, dass der Code im Modell und im ViewModel unter Unit Test gestellt werden kann. Der Hauptzweck von MVVM besteht darin, dass der Code in Klassen mit einer kleinen Anzahl genau definierter Verantwortlichkeiten unterteilt wird. Einer von mehreren Vorteilen eines Codes, der aus Klassen mit einer geringen Anzahl genau definierter Verantwortlichkeiten besteht, besteht darin, dass es einfacher ist, den Code einem Unit-Test zu unterziehen. Ein viel größerer Vorteil ist, dass der Code leichter zu verstehen, zu warten und zu ändern ist.

Das Implementieren von Mustern und das Befolgen von Best Practices fühlen sich oft sinnlos an, aber Sie werden zu einem Konvertiten, wenn Ihr Chef Sie Monate später auffordert, eine Funktion hinzuzufügen oder zu optimieren. Mit MVVM (und Mustern im Allgemeinen) können Sie tatsächlich Ihrem eigenen Code folgen und die Anforderung im schlimmsten Fall in wenigen Stunden oder Tagen anstatt in Wochen oder Monaten erfüllen. (Bei dieser Änderung handelt es sich wahrscheinlich nur um ein paar Codezeilen, anstatt Wochen damit zu verbringen, herauszufinden, wie Sie das getan haben, was Sie ursprünglich getan haben, bevor Sie überhaupt versucht haben, neue Funktionen hinzuzufügen.)

Follow-up: Muster und Best Practices verlangsamen die anfängliche Entwicklung und das ist für Management und Engineering oft ein schwerer Verkauf. Die Amortisation (ROI in biz-Begriffen) ergibt sich aus 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 Austauschen einer gesamten Ansicht, ohne dass dies Auswirkungen auf die Daten- und Geschäftslogik hat.

Ein Gedanke zur Verwendung von Datensätzen für Ihr Modell : (Ich bin auch darauf hereingefallen.) Datensätze scheinen eine absolut gültige Methode zu sein, um Modelldaten in einer Anwendung zu verschieben. 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 logischen Elemente bedeuten, dass Sie in Ihrer Anwendung magische Zeichenfolgen und Zahlen in der Verdrahtungslogik verwenden müssen. Die Verwendung eines typisierten Datensatzes würde einige dieser Probleme beheben, jedoch nicht vollständig. Mit typisierten Datasets würden Sie sich von MVVM entfernen und eine engere Kopplung zwischen der Benutzeroberfläche und der Datenquelle herstellen.

Es hilft Ihnen bei der Trennung von GUI und Programmlogik. Das Mischen kann zu sehr schwer zu wartenden Anwendungen führen, insbesondere wenn Ihr Projekt mit der Zeit wächst.

Von hier aus :

Warum sollten Sie sich als Entwickler überhaupt für das Model-View-ViewModel-Muster interessieren? Dieses Muster bietet eine Reihe von Vorteilen für die Entwicklung von WPF und Silverlight. Bevor Sie fortfahren, fragen Sie sich:

• Müssen Sie ein Projekt mit einem Designer teilen und die Flexibilität haben, dass Design- und Entwicklungsarbeiten nahezu gleichzeitig ausgeführt werden?
• Benötigen Sie gründliche Unit-Tests für Ihre Lösungen?
• Ist es für Sie wichtig, wiederverwendbare Komponenten innerhalb und zwischen Projekten in Ihrem Unternehmen zu haben?
• Möchten Sie mehr Flexibilität beim Ändern Ihrer Benutzeroberfläche, ohne andere Logik in der Codebasis umgestalten zu müssen?

Wenn Sie eine dieser Fragen mit "Ja" beantwortet haben, sind dies nur einige der Vorteile, die die Verwendung des MVVM-Modells für Ihr Projekt bringen kann.

• Es ist einfacher, mit Designern zu arbeiten (nicht mit Programmierern, sondern nur mit Leuten, die Blend verwenden).
• 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 das Modell verspotten und Ihre Benutzeroberfläche entwickeln, ohne einen echten Dienst auszuführen (nur Mock-Daten aus dem Modell verwenden). Dann drehen Sie einfach das Flag und stellen eine Verbindung zum Dienst her.

Aus Josh Smiths Artikel über MVVM :

Zusätzlich zu den WPF- (und Silverlight 2-) Funktionen, die MVVM zu einer natürlichen Methode zum Strukturieren einer Anwendung machen, ist das Muster auch beliebt, da ViewModel-Klassen einfach zu testen sind. Wenn die Interaktionslogik einer Anwendung in einer Reihe von ViewModel-Klassen gespeichert ist, können Sie problemlos Code schreiben, der sie testet. In gewisser Weise sind Ansichten und Komponententests nur zwei verschiedene Arten von ViewModel-Verbrauchern. Eine Reihe von Tests für die ViewModels einer Anwendung bietet kostenlose und schnelle Regressionstests, mit denen die Kosten für die Wartung einer Anwendung im Laufe der Zeit gesenkt werden können.

Für mich ist dies der wichtigste Grund, MVVM zu verwenden.

Vorher 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? MVVM behebt dieses Problem, da es die nicht testbare Ansicht vom testbaren Ansichtsmodell trennt und die Ansichtsebene so dünn wie möglich hält.

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

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

Lesen Sie die Einführung in MVVM in diesem Artikel

Im Jahr 2005 stellte John Gossman, derzeit einer der WPF- und Silverlight-Architekten bei Microsoft, das MVVM-Muster (Model-View-ViewModel) in seinem Blog vor. MVVM ist insofern identisch mit Fowlers Präsentationsmodell, als beide Muster eine Abstraktion einer Ansicht enthalten, die den Status und das Verhalten einer Ansicht enthält. Fowler führte das Präsentationsmodell ein, um eine plattformunabhängige Abstraktion einer Ansicht auf der Benutzeroberfläche zu erstellen, während Gossman MVVM als standardisierte Methode einführte, um die Kernfunktionen von WPF zu nutzen und die Erstellung von Benutzeroberflächen zu vereinfachen. In diesem Sinne betrachte ich MVVM als 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 ist an Eigenschaften in einem ViewModel gebunden, wodurch Daten in Modellobjekten und anderen für die Ansicht spezifischen Status verfügbar gemacht werden. 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 an die Ansicht weitergegeben. 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 Ansicht, führt alle an den Modelldaten vorgenommenen Änderungen durch. Die Ansichtsklassen haben keine Ahnung, dass die Modellklassen vorhanden sind, während ViewModel und Modell die Ansicht nicht kennen. Tatsächlich ist sich das Modell der Tatsache, dass das ViewModel und die Ansicht vorhanden sind, überhaupt nicht bewusst.

Der Artikel erklärt auch, warum diese GUI-Muster verwendet werden:

Es ist unnötig und kontraproduktiv, Entwurfsmuster in einem einfachen "Hallo Welt!" Programm. Jeder kompetente Entwickler kann einige Codezeilen auf einen Blick verstehen. Mit zunehmender Anzahl von Features in einem Programm nimmt jedoch die Anzahl von Codezeilen und beweglichen Teilen entsprechend zu. Die Komplexität eines Systems und die darin enthaltenen wiederkehrenden Probleme ermutigen Entwickler schließlich, ihren Code so zu organisieren, dass es einfacher ist, ihn zu verstehen, zu diskutieren, zu erweitern und Fehler zu beheben. Wir verringern das kognitive Chaos eines komplexen Systems, indem wir bestimmten Entitäten im Quellcode bekannte Namen zuweisen. Wir bestimmen den Namen, der auf einen Code angewendet werden soll, indem wir dessen funktionale Rolle im System berücksichtigen.

Entwickler strukturieren ihren Code häufig absichtlich nach einem Entwurfsmuster, anstatt die Muster organisch entstehen zu lassen. An beiden Ansätzen ist nichts auszusetzen, aber in diesem Artikel untersuche ich 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. das Ende 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 bei den meisten professionellen Softwareentwicklungsprojekten der natürliche Zustand ist!

Ich werde mich immer noch selbst mit dem Muster auseinandersetzen, aber ich denke, es ist wertvoll. Die derzeit größte Herausforderung besteht darin, 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 einige Dinge entdeckt, die mir sehr geholfen haben, das Muster sauberer umzusetzen:

1. Ich benutze den RelayCommand von Josh Smiths MVVM Foundation intensiv . Dies macht die Bindung von View zu ViewModel über Befehle viel sauberer.

2. Ich verwende AOP, um die Implementierung von INotifyPropertyChanged zu vereinfachen. 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 inzwischen aufgegeben, da mich der Boilerplate-Code zur manuellen Implementierung wirklich nervte.

3. Ich musste meinen Ansatz zur Implementierung der Software umkehren. Anstatt eine Diktatorklasse zu haben, die allen Schergen sagt, was zu tun ist, die wiederum ihre Schergen verwenden, wird meine Software eher zu einer Angelegenheit von lose gekoppelten Diensten, die sagen:

   • Das weiß ich zu tun

   • Dies sind die Dinge, die ich getan haben muss

Wenn Sie anfangen, Ihren Code auf diese Weise zu strukturieren und Tools verwenden, mit denen sich die Abhängigkeiten leicht verkabeln lassen (es stehen eine Vielzahl von IoC-Frameworks zur Auswahl), habe ich festgestellt, dass dies die Unbeholfenheit von MVVM erleichtert Sie können den Boilerplate-Code reduzieren, der mit dem Einfügen der Modelle in die ViewModels und dem Auffinden verschiedener View Services (z. B. Anzeigen von Dateidialogen) für Ihre ViewModels verbunden ist.

Es ist eine enorme Investition, diesen anderen Ansatz zu erlernen, und wie bei jeder größeren Änderung der Implementierung ist die Produktivität viel geringer, wenn Sie ihn zum ersten Mal verwenden. Am Ende des Tunnels sehe ich jedoch allmählich etwas Licht und ich glaube, dass meine Anwendungen sauberer und wartbarer sind, sobald ich die unordentlichen Details beherrsche.

Um die Frage zu INotifyPropertyChanged über Postsharp zu beantworten, verwende ich einen Aspekt, der auf dem Beispiel hier basiert . Ich habe es ein wenig für meinen Gebrauch angepasst, aber das gibt Ihnen den Kern davon. Damit tagge ich einfach die Klasse [NotifyPropertyChanged] und in allen öffentlichen Eigenschaften wird das Muster in ihren Setzern implementiert (auch wenn es sich um Setter mit automatischen Eigenschaften handelt). Es fühlt sich für mich viel sauberer an, da ich mir keine Sorgen mehr machen muss, ob ich mir die Zeit nehmen möchte, damit die Klasse INotifyPropertyChanged implementiert. Ich kann einfach das Attribut hinzufügen und damit fertig sein.

Ich bin damit einverstanden, dass die Verwendung von MVVM durch das Schreiben von Erzcode mehr Gewicht auf unsere Schultern legt. Schauen Sie sich jedoch die gute Seite an, auf der alles isoliert ist. Wenn Sie Designer sind, können Sie Ihr Programm entwerfen und andere können es für Sie und andere für die Datenbank codieren Schicht für Sie, schauen Sie, in welcher wartbaren Umgebung Sie sich gerade in großen Unternehmensanwendungen befinden, wenn Sie MVVM nicht verwenden würden, dann ist die Wartung fast tödlich .... Ich selbst habe sie bei der Entwicklung einer ERP-Lösung verwendet, jetzt ist die Wartung ziemlich einfach, weil dieser Isolationsstufe

Sie werden auf lange Sicht glücklich sein, wenn Sie ein Muster wie MVVM aus all den Gründen verwenden, die die anderen veröffentlicht haben. Denken Sie daran, dass Sie die Musteranforderungen nicht Wort für Wort befolgen müssen. Stellen Sie lediglich sicher, dass Sie eine gute Trennung zwischen Ihrem Fenster (Ansicht) und Ihrer Logik (CodeBehind) haben.

Vorteile von MVVM

1. Reduzierte Komplexität.
2. Isolierung von Design und Entwicklung.
3. Abhängigkeitsspritze.
4. Der Hauptvorteil besteht darin, dass Sie eine gut MVVM-strukturierte Windows Phone-Anwendung haben und diese für Windows Metro Desktop entwickeln möchten. Sie möchten sich nur auf das Design konzentrieren, da dasselbe Ansichtsmodell verwendet werden kann, wie es ist.

Ich hoffe es hilft.

MVVM ist wirklich übermäßiger Code.

Welche Vorteile bietet die MVVM?

Es ist nur eine Trennung von Bedenken, nicht mehr. Sie können auch die ViewModel-Logik in den Controller schreiben. Das ViewModel ist nur für eine Konvertierung verantwortlich (z. B. und Objekt in eine Zeichenfolge). Durch die Verwendung von MVVM verwenden Sie einen objektorientierteren Programmierstil. Durch 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 kann man nicht sagen, dass man MVVM verwenden muss, da es besser ist als MVC oder so, es ist nur eine persönliche Präferenz.

Um ganz 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.