Unter welchen Bedingungen ist die Verwendung von MVVM angemessen?

Model View View-Model wurde von Microsoft für Benutzeroberflächen-Entwicklungsplattformen entwickelt, die ereignisgesteuerte Programmierung unterstützen, insbesondere Windows Presentation Foundation (WPF) und Silverlight auf .NET-Plattformen mit XAML- und .NET-Sprachen. In den letzten Jahren haben viele Javascript-Frameworks wie Angular, Knockout und ExtJS das Muster übernommen.

Wie die meisten Softwaremuster hat MVVM die entsprechenden Verwendungen und Missbräuche. Unter welchen Bedingungen ist die Verwendung von MVVM angemessen? Wann ist es schlecht beraten?

MVVM soll verwendet werden, wenn komplexe Benutzerinteraktionen unter Verwendung von High-Fidelity-Benutzeroberflächen (z. B. WPF ) erforderlich sind .

MVVM richtet sich an moderne UI-Entwicklungsplattformen (Windows Presentation Foundation oder WPF und Silverlight), bei denen es einen User Experience (UXi) -Entwickler gibt, dessen Anforderungen sich von denen eines "traditionelleren" Entwicklers unterscheiden (z. B. orientiert an Geschäftslogik und Backend-Entwicklung). Das Ansichtsmodell von MVVM ist „im Grunde genommen ein Wertekonverter für Steroide“, was bedeutet, dass das Ansichtsmodell dafür verantwortlich ist, die Datenobjekte aus dem Modell so verfügbar zu machen, dass diese Objekte einfach verwaltet und verwendet werden können. In dieser Hinsicht ist das Ansichtsmodell mehr Modell als Ansicht und verarbeitet die meisten, wenn nicht alle Anzeigelogiken der Ansicht.

MVVM wurde so konzipiert, dass bestimmte Funktionen in WPF verwendet werden, um die Trennung der View-Ebenenentwicklung vom Rest des Musters zu erleichtern, indem praktisch alle "Code-Behinds" aus der View-Ebene entfernt werden. Anstatt dass Interactive Designer View-Code schreiben müssen, können sie die native WPF-Markup-Sprache XAML verwenden und Bindungen an das ViewModel erstellen, das von Anwendungsentwicklern geschrieben und verwaltet wird. Diese Aufteilung der Rollen ermöglicht es Interactive Designers, sich auf die Anforderungen von UX zu konzentrieren und nicht auf die Programmierung oder Geschäftslogik. Auf diese Weise können die Ebenen einer Anwendung in mehreren Arbeitsabläufen entwickelt werden.

Für Benutzeroberflächen, in denen diese Art von intensiver Interaktion nicht erforderlich ist, ist MVVM möglicherweise zu viel des Guten. MVP kann eine natürlichere Wahl sein. Für Webanwendungen ist MVC besser geeignet. Für sehr kleine Anwendungen, die niemals größer werden (z. B. kleine Winforms-Dienstprogramme), ist CodeBehind ausreichend.

Manchmal kann MVVM eine Falle sein. Meiner Erfahrung nach werden CRUD-ähnliche Anwendungen (Formulare gegenüber Daten) gegenüber aufgabenorientierteren Benutzeroberflächen bevorzugt. Ich sage nicht, dass dies eine schlechte Architektur für das Back-End / andere Ebenen in der Anwendung impliziert, aber ich habe viele MVVM-Anwendungen mit einer "DDD-Light" -Architektur gesehen. Ich weiß nicht warum genau, vielleicht, weil das Binden so einfach ist und es sehr einfach ist, eine Anwendung mit ORM und MVVM / Binden unter Verwendung von POCO / Anämischen Domänenobjekten einzurichten.

MVVM ist ein Pflaster für schlecht gestaltete Datenbindungsschichten. Insbesondere in der WPF / silverlight / WP7-Welt hat es aufgrund der Einschränkungen bei der Datenbindung in WPF / XAML viel Verwendung gefunden.

Von nun an gehe ich davon aus, dass wir über WPF / XAML sprechen, da dies die Dinge klarer machen wird. Schauen wir uns einige der Mängel an, die MVVM in WPF / XAML zu beheben versucht.

Datenform vs UI-Form

Die 'VM' in MVVM erstellt eine Reihe von in C # definierten Objekten, die einer Reihe von in XAML definierten Präsentationsobjekten zugeordnet werden. Diese C # -Objekte sind in der Regel über DataContext-Eigenschaften für Präsentationsobjekte mit XAML verbunden.

Infolgedessen muss das Ansichtsmodell-Objektdiagramm dem Präsentationsobjektdiagramm Ihrer Anwendung zugeordnet werden. Das heißt nicht, dass die Zuordnung eins zu eins erfolgen muss. Wenn jedoch ein Listensteuerelement in einem Fenstersteuerelement enthalten ist, muss es eine Möglichkeit geben, vom DataContext-Objekt des Fensters zu einem Objekt zu gelangen, das die Daten dieser Liste beschreibt.

Das Ansichtsmodell-Objektdiagramm entkoppelt das Modellobjektdiagramm erfolgreich vom UI-Objektdiagramm, jedoch auf Kosten eines zusätzlichen Ansichtsmodell-Layers, der erstellt und verwaltet werden muss.

Wenn ich einige Daten von Bildschirm A auf Bildschirm B verschieben möchte, muss ich mit Ansichtsmodellen herumspielen. Für einen Geschäftsmann ist dies eine Änderung in der Benutzeroberfläche. Es sollte rein in der Welt von XAML stattfinden. Leider kann es selten. Schlimmer noch, je nachdem, wie die Ansichtsmodelle strukturiert sind und wie aktiv sich die Daten ändern, kann ein beträchtlicher Teil der Datenumleitung erforderlich sein, um diese Änderung durchzuführen.

Umgehen der unexpressiven Datenbindung

WPF / XAML-Bindungen sind nicht ausreichend aussagekräftig. Grundsätzlich müssen Sie einen Weg angeben, um zu einem Objekt zu gelangen, einen Eigenschaftspfad zum Durchlaufen und Bindungskonverter, um den Wert der Dateneigenschaft an die Anforderungen des Präsentationsobjekts anzupassen.

Wenn Sie eine Eigenschaft in C # an etwas Komplexeres binden müssen, haben Sie im Grunde kein Glück. Ich habe noch nie eine WPF-App ohne einen Bindungskonverter gesehen, der aus wahr / falsch Sichtbar / Reduziert wurde. Viele WPF-Apps haben auch NegatingVisibilityConverter oder ähnliches, das die Polarität umkehrt. Dies sollte Alarmglocken auslösen.

MVVM enthält Richtlinien für die Strukturierung Ihres C # -Codes, mit denen diese Einschränkung behoben werden kann. Sie können eine Eigenschaft in Ihrem Ansichtsmodell mit dem Namen SomeButtonVisibility verfügbar machen und sie einfach an die Sichtbarkeit dieser Schaltfläche binden. Ihre XAML ist jetzt nett und hübsch ... aber Sie haben sich zum Angestellten gemacht - jetzt müssen Sie Bindungen an zwei Stellen (der Benutzeroberfläche und dem Code in C #) anzeigen und aktualisieren, wenn sich Ihre Benutzeroberfläche weiterentwickelt. Wenn Sie dieselbe Schaltfläche auf einem anderen Bildschirm benötigen, müssen Sie eine ähnliche Eigenschaft in einem Ansichtsmodell verfügbar machen, auf das dieser Bildschirm zugreifen kann. Schlimmer noch, ich kann nicht nur auf die XAML schauen und sehen, wann die Schaltfläche nicht mehr sichtbar ist. Sobald Bindungen nicht mehr ganz einfach sind, muss ich Detektivarbeit im C # -Code leisten.

Der Zugriff auf Daten ist sehr umfangreich

Da Daten in der Regel über DataContext-Eigenschaften in die Benutzeroberfläche eingegeben werden, ist es schwierig, globale oder Sitzungsdaten in der gesamten App konsistent darzustellen.

Die Idee des "derzeit angemeldeten Benutzers" ist ein gutes Beispiel - dies ist häufig eine wirklich globale Sache in einer Instanz Ihrer App. In WPF / XAML ist es sehr schwierig, den globalen Zugriff auf den aktuellen Benutzer auf konsistente Weise sicherzustellen.

Ich möchte das Wort "CurrentUser" in Datenbindungen frei verwenden, um auf den aktuell angemeldeten Benutzer zu verweisen. Stattdessen muss ich sicherstellen, dass mir jeder DataContext eine Möglichkeit gibt, zum aktuellen Benutzerobjekt zu gelangen. MVVM kann dies ausgleichen, aber die Ansichtsmodelle werden ein Chaos sein, da alle von ihnen Zugriff auf diese globalen Daten gewähren müssen.

Ein Beispiel, in dem MVVM umfällt

Angenommen, wir haben eine Liste von Benutzern. Neben jedem Benutzer soll die Schaltfläche "Benutzer löschen" angezeigt werden, jedoch nur, wenn der aktuell angemeldete Benutzer ein Administrator ist. Benutzer dürfen sich auch nicht selbst löschen.

Ihre Modellobjekte sollten nichts über den aktuell angemeldeten Benutzer wissen - sie stellen lediglich Benutzerdatensätze in Ihrer Datenbank dar, aber irgendwie muss der aktuell angemeldete Benutzer Datenbindungen in Ihren Listenzeilen ausgesetzt sein. MVVM schreibt vor, dass wir für jede Listenzeile, die den aktuell angemeldeten Benutzer mit dem durch diese Listenzeile dargestellten Benutzer zusammensetzt, ein Ansichtsmodellobjekt erstellen und dann für dieses Ansichtsmodellobjekt eine Eigenschaft mit dem Namen "DeleteButtonVisibility" oder "CanDelete" verfügbar machen sollen (abhängig von Ihren Gefühlen) über Bindungskonverter).

Dieses Objekt wird in den meisten anderen Aspekten einem Benutzerobjekt sehr ähnlich sein - es muss möglicherweise alle Eigenschaften des Benutzermodellobjekts widerspiegeln und Aktualisierungen an diese Daten weiterleiten, wenn sie sich ändern. Dies fühlt sich wirklich unangenehm an - MVVM macht Sie zu einem Angestellten, indem es Sie zwingt, dieses benutzerähnliche Objekt zu verwalten.

Beachten Sie, dass Sie wahrscheinlich auch die Eigenschaften Ihres Benutzers in einer Datenbank, im Modell und in der Ansicht darstellen müssen. Wenn Sie eine API zwischen sich und Ihrer Datenbank haben, ist dies schlimmer: Sie sind in der Datenbank, dem API-Server, dem API-Client, dem Modell und der Ansicht dargestellt. Ich würde wirklich zögern, ein Entwurfsmuster zu übernehmen, das eine weitere Ebene hinzufügt, die jedes Mal berührt werden muss, wenn eine Eigenschaft hinzugefügt oder geändert wird.

Schlimmer noch, diese Ebene skaliert mit der Komplexität Ihrer Benutzeroberfläche und nicht mit der Komplexität Ihres Datenmodells. Häufig werden dieselben Daten an vielen Stellen und in Ihrer Benutzeroberfläche dargestellt - dies fügt nicht nur eine Ebene hinzu, sondern eine Ebene mit viel zusätzlicher Oberfläche!

Wie es hätte sein können

In dem oben beschriebenen Fall möchte ich sagen:

<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />

CurrentUser wird in meiner App global für alle XAML-Dateien verfügbar gemacht. ID verweist auf eine Eigenschaft im DataContext für meine Listenzeile. Die Sichtbarkeit wird automatisch vom Booleschen Wert konvertiert. Alle Aktualisierungen von Id, CurrentUser.IsAdmin, CurrentUser oder CurrentUser.Id lösen eine Aktualisierung der Sichtbarkeit dieser Schaltfläche aus. Kinderleicht.

Stattdessen zwingt WPF / XAML seine Benutzer, ein vollständiges Durcheinander zu erstellen. Soweit ich das beurteilen kann, haben einige kreative Blogger diesem Chaos einen Namen gegeben, und dieser Name war MVVM. Lass dich nicht täuschen - es ist nicht in der gleichen Klasse wie die GoF-Designmuster. Dies ist ein hässlicher Hack, um ein hässliches Datenbindungssystem zu umgehen.

(Dieser Ansatz wird manchmal als "Functional Reactive Programming" bezeichnet, falls Sie weitere Informationen benötigen.)

Abschließend

Wenn Sie in WPF / XAML arbeiten müssen, empfehle ich MVVM immer noch nicht.

Sie möchten, dass Ihr Code so strukturiert ist, wie es oben im Beispiel "Wie die Dinge hätten sein können" beschrieben wurde - das Modell wird direkt in der Ansicht angezeigt, mit komplexen Datenbindungsausdrücken und flexiblen Werteberechnungen. Es ist viel besser - lesbarer, beschreibbarer und wartbarer.

MVVM weist Sie an, Ihren Code ausführlicher und weniger wartbar zu strukturieren.

Erstellen Sie statt MVVM ein paar Dinge, die Ihnen dabei helfen, die gute Erfahrung zu schätzen: Entwickeln Sie eine Konvention, um den globalen Status konsistent für Ihre Benutzeroberfläche verfügbar zu machen. Bauen Sie sich Werkzeuge aus Bindungskonvertern, MultiBinding usw. auf, mit denen Sie komplexere Bindungsausdrücke ausdrücken können. Bauen Sie sich eine Bibliothek mit Bindungskonvertern auf, um häufige Fälle von Nötigung weniger schmerzhaft zu machen.

Noch besser - ersetzen Sie XAML durch etwas aussagekräftigeres. XAML ist ein sehr einfaches XML-Format zum Instanziieren von C # -Objekten - eine ausdrucksstärkere Variante wäre nicht schwer zu finden.

Meine andere Empfehlung: Verwenden Sie keine Toolkits, die solche Kompromisse erzwingen. Sie beeinträchtigen die Qualität Ihres Endprodukts, indem sie Sie in Richtung MVVM treiben, anstatt sich auf Ihre Problemdomäne zu konzentrieren.

Ich mag MVVM sehr und finde seine Herausforderungen motivierend und sehe die vielen Vorteile, aber ...

1. Für Anwendungen oder Spiele, die viel Benutzeroberflächen- / Interaktionscode erfordern, um eine Menge benutzerdefinierter Verhaltensweisen hinzuzufügen, während die Leistung erhalten bleibt - es ist oft besser, ein bisschen schmutziges MVVM zu verwenden - verwenden Sie es, wenn es nützlich ist oder sich auf Daten konzentriert, im Gegensatz zu interaktionszentrierte Bereiche des Codes. Angenommen, Sie möchten ein Steuerelement erstellen und zwischen verschiedenen übergeordneten Steuerelementen verschieben oder es auf andere Weise zwischenspeichern ...

2. Es hat eine ziemlich steile Lernkurve. Wenn Sie also nicht genug Zeit haben, planen Sie, viel in WPF / SL zu entwickeln, Designer mit Blend-Kenntnissen zu haben, das Bedürfnis zu verspüren, Testcode für Ihre Benutzeroberfläche zu schreiben oder auf andere Weise jahrelange Wartungsarbeiten für Ihre Benutzeroberfläche durchzuführen Projekt - es könnte sich nicht auszahlen.

3. Nicht so viele Designer kennen Blend, nicht alle Projekte sind es wert, das automatisierte Testen auf die Präsentationsebene zu konzentrieren, da es ohnehin manuell getestet werden muss, und so finden Sie die wichtigsten Fehler, nicht durch Testen Ihrer VMs.

4. Es ist wirklich eine Investition. Sie müssen sich zuerst mit den Grundlagen von WPF / SL und XAML vertraut machen, dann die Möglichkeiten herausfinden, wie Sie die Bindungen richtig ausführen, sich in einer bestimmten Reihenfolge mit VMS verbinden, Ihre Befehle richtig ausführen und in den meisten Fällen ein Framework auswählen, das dies könnte Aufgrund der Lizenzierung ist es problematisch, eine Sippets-Bibliothek zu erstellen, um effizient zu codieren. Dabei muss festgestellt werden, dass die Plattform nicht immer gut mit Bindungen funktioniert und eine Bibliothek mit Verhaltensweisen erstellt werden muss, mit denen Sie das bekommen, was Sie benötigen.

Alles in allem zahlt sich dies jedoch aus, wenn Sie alle Hürden überwinden und das Muster ziemlich gut beherrschen. :)

Ich bin seit Jahren ein WPF / Silverlight-Programmierer, der große Anwendungen wie Handelssysteme auf MVVM erstellt.

Im Laufe der Jahre habe ich gelernt, dass strenge MVVM Zeit verschlingt und Geld kostet. Mit streng meine ich Regeln wie "kein Code dahinter".

Es ist in nichts anderem als der einfachsten Form / Datenbank-App unmöglich, keinen Code-Behind zu haben.

Ihr Designer wird am ersten Tag etwas spezifizieren, das mit den Standardsteuerelementen nicht möglich ist. Sie müssen daher eine Reihe benutzerdefinierter Steuerelemente erstellen oder vorhandene Steuerelemente umbrechen, um das Interaktionsparadigma bei der Arbeit mit MVVM zu unterstützen.

Ich habe alle Arten von Swish-UI-Steuerelementen unter Verwendung von Mathematik, Trägheit, Gesten usw. und ihrer harten Arbeit geschrieben.

Aber das ist alles Code-Behind, es ist einfach nicht in der Ansicht. Sie müssen mit Tastenklicks, Scrollen, Ziehen usw. umgehen, aber alles ist gut in einer Reihe von Steuerelementen zusammengefasst, was diesen Code-Behind irgendwie in Ordnung macht.

Es ist oft einfacher, einfach den Code hinter und die raffinierten UI-Elemente in die Ansicht zu schreiben, anstatt eine Reihe von Steuerelementen zu erstellen, nur um dies zu erreichen.

Das Ziel von MVVM besteht darin, die Anwendungs- / Geschäftslogik von der Benutzeroberflächenlogik zu trennen. Das Bindungssystem und MVVM sind eine gute Möglichkeit, dies zu tun.

Die anderen angepriesenen Ziele, wie der XAML-Designer auf einem Schreibtisch, der C # -Programmierer auf dem anderen, der in Blend und der andere in VS arbeitet, sind ein Irrtum.

Die Möglichkeit, eine Benutzeroberfläche schnell umzugestalten, ist ein weiterer Irrtum. Es passiert nie, seine vorzeitige Optimierung; Jede größere Überarbeitung erfordert viel Arbeit an den Ansichtsmodellen. Optimierungen sind eine Sache, aber eine schnelle Überarbeitung der Benutzeroberfläche ist nicht möglich. Die Ansichtsmodelle müssen zum Interaktionsparadigma passen, sodass die Kopplung enger ist, als Sie vielleicht denken.

Für mich verwende ich MVVM, um meine Anwendungslogik getrennt zu halten (ich verwende normalerweise einen testbaren Controller und eine Reihe von logiklosen Ansichtsmodellen) Schwitzen.

Andernfalls werden Sie Ihre Designs, coolen Animationen usw. beherrschen, nur weil die Idee, wie Sie MVVM erstellen können, zu umwerfend wird.

MVVM hat, wie die meisten Dinge im Leben, einen Sweet Spot zwischen zwei Extremen.

Das Wichtigste beim Software-Design ist, dass Sie Ihr Produkt frühzeitig ausliefern, herausfinden, welche Funktionen verwendet werden, welche Benutzeroberfläche gut funktioniert und keinen schönen Code für ein Produkt schreiben, das niemand verwendet.

Wenn Ihre Anwendung erfordert, dass Sie übermäßige Datenmengen in Echtzeit binden, kann MVVM tatsächlich stören, da es Abstraktionen einführt, die den Prozess verlangsamen, und vorausgesetzt, wir sprechen gerade über WPF / Silverlight / WP7, die Bindung Motor ist derzeit nicht so effizient; obwohl Verbesserungen auf dem Weg sind.

MVVM ist nicht der einzige Teil der Gleichung, den Sie berücksichtigen müssen. Pure MVVM muss mit einer Infrastruktur wie dem Mediator-Muster unterstützt werden, damit Sie über getrennte ViewModels hinweg kommunizieren können.

Trotz der obigen Meinung von blucz liegt MVVM in der Linie der GoF-Muster. Wenn Sie sich die Muster ansehen, entspricht MVVM dem Model View Passive Presenter-Muster, das ungefähr zur gleichen Zeit wie MVVM angezeigt wurde. Sie werden sich hier oft über die Komplexität von MVVM beschweren, nur weil sie nicht verstehen, wie man damit entwirft.

Ein weiterer Bereich, in dem ich Probleme mit MVVM festgestellt habe, ist die Einbindung einer Technologie von Drittanbietern, die diese nicht unterstützt (z. B. das UII-Framework für MS Dynamics). Manchmal muss man sich fragen, ob es sich lohnt, die andere Technologie zu "hacken", nur um mit MVVM zu arbeiten.

Wenn Sie so etwas wie Win Forms in Ihre WPF-Lösung mischen und abgleichen, ist dieser Teil der Lösung wahrscheinlich auch nicht für MVVM geeignet. Ich hoffe, dies gibt Ihnen eine Vorstellung von einigen Bereichen, in denen MVVM nicht anwendbar ist.

Die Verwendung von MVVM ist nicht sinnvoll, wenn:

• Sie arbeiten nicht mit WPF oder Silverlight
• Sie testen ein Konzept

Das ist es. Ich kann mir nicht vorstellen, warum Sie MVVM NICHT verwenden würden, wenn Sie mit WPF / Silverlight arbeiten, es sei denn, Sie testen oder debuggen etwas in einem separaten Projekt. Ich finde das Designmuster aufgrund der Funktionsweise der XAML-Bindungen ideal für die WPF / Silverlight-Entwicklung.

Der springende Punkt von MVVM ist, dass Ihre gesamte Anwendung in Ihren ViewModels ausgeführt wird und Ihre Ansichten einfach eine hübsche Ebene sind, mit der Benutzer mit Ihren ViewModels interagieren können. Wenn Sie auf eine Schaltfläche klicken möchten, wird tatsächlich eine ViewModel-Methode ausgeführt. Wenn Sie die Seite ändern möchten, ändern Sie tatsächlich die CurrentPage-Eigenschaft im ViewModel.

Ich verwende MVVM für alle WPF / Silverlight-Entwicklungen, auch für kleine, einfache einseitige Projekte. Die Verwendung von MVVM hängt jedoch von der Größe des Projekts und meinen Anforderungen ab. Als ich einmal eine kleine App ohne MVVM gemacht habe, habe ich es letztendlich bereut (später wurde die Verwendung von MVVM beim Hinzufügen eines Updates überarbeitet)

Ich habe für einen Kunden an einem Projekt gearbeitet, das Code-Behind war, mit dem Versuch, auf MVVM umzusteigen, und es war ein riesiges Durcheinander. Das heißt nicht, dass alle Code-Behind-Projekte ein Chaos sind. Die Ansichten würden Blend fehlerhaft oder zum Absturz bringen, was den Designern Probleme bereitete.

Ich habe mich in RoR vertieft und mit ASP.NET Webforms so ziemlich alles übersprungen, aber als ASP.NET MVC herauskam, habe ich versucht, so viel wie möglich zu lernen, wobei ich häufig die ASP.NET MVC In Action-Bücher und den Codecamp-Server als Referenz verwendete . Obwohl es sich um ein anderes Muster handelt, verwende ich viele der Dinge, die ich aus den In-Action-Büchern in der SL / MVVM-Entwicklung gelernt habe.

Als ich anfing, mit Silverlight zu arbeiten, war ich überrascht, wie nackt es war, und es schien mir eine Notwendigkeit zu sein, eines der vielen verfügbaren Frameworks zu wählen, um es zu verkleiden. Ich sehe dies als Problem, wenn Leute aufhören, MVVM zu lernen.

Ich habe mit dem exzellenten MVVM-Light angefangen, das mir geholfen hat, das Muster zu verstehen. Ich fing später an, mit Caliburn Micro zu arbeiten, und dann gingen die Lichter an. Für mich ist Caliburn Micro mit der Verwendung von ASP.NET MVC über ASP.NET Webforms vergleichbar. Selbst für kleine Beispielanwendungen erstelle ich das Projekt NuGet CM und kann loslegen. Ich folge dem ersten Ansatz von ViewModel und halte meine Ansichten in Blend für dumm und einfach zu bearbeiten. Meine VMs können getestet werden, wenn Sie sich damit beschäftigen, und mit CM ist es ziemlich einfach, komplexe Bildschirmlayouts zu umgehen.

Sie können diese Alternative gerne ausprobieren. Diese Option umgeht die WPF-Methode für Datenbindung, Datenvorlagen und MVVM. Diese Option ähnelt eher dem alten, einfachen und zuverlässigen Ansatz von WinForms designer.cs.

WPF-Verbundwerkstoffe

http://wpfcomposites.codeplex.com/

Hier wird ein präzises C # -Code-Behind für WPF erstellt, indem eine einfache Matrix über der Benutzeroberfläche über gitterbasierte Verbundwerkstoffe gelegt wird. Wenn eine moderne XAML-Benutzeroberfläche nur wenige Textbeschriftungen und eine Listbox mit Fotos enthält, warum kann dies nicht durch die einfache Codezeile grid.AddText (guid, x-Koordinate, y-Koordinate) definiert werden? Beachten Sie, dass dies nicht auf einer Leinwand ist, sondern sich immer noch in den WPF-Containern befindet: Raster, Dockpanel usw. WPF ist enorm leistungsfähig. Dieser Ansatz nutzt dies lediglich.

Entwickler haben normalerweise nichts gegen Matrizen und Indizes. Beginnen Sie mit einer grobkörnigen Containerebene, die durch die GUIDs von Data Transfer Objects (DTOs) oder POCOs definiert ist, und ergänzen Sie diese verschlüsselten Container durch eine feinkörnigere Matrix potenzieller Zeilen und Spalten innerhalb von?

Das obige Codeplex-Projekt führt diesen Ansatz ein, indem es mit dem ListBox-Steuerelement beginnt, sich jedoch auf alle zusammengesetzten WPF-Steuerelemente erstreckt. Beispielsweise ist jedes Listbox-Element ein Composite, dem eine GUID hinzugefügt wurde (ein Composite verknüpft eins zu eins mit einer Klasse). In diesem Element befindet sich dann ein Grid, in dem untergeordnete UI-Elemente (untergeordnete Elemente verknüpfen eins zu eins mit Eigenschaften) in einer Klasse) kann per Code-Behind nach Belieben hinzugefügt werden. Kinder können Textblöcke oder Bilder sein.

Die Idee ist, Indizes und eine gut definierte UI-Element-Struktur zu nutzen (sie erzwingt eine ListBox mit dem PresentationFramework.Aero-Thema als Basis) anstelle von Datenvorlagen. Dieser neue Ansatz begrenzt absichtlich das, was getan werden kann, ergibt aber auf diese Weise einen präzisen, robusten C # -Code-Behind, der intuitiv ist. Sie müssen keine Kontrollvorlagenlösungen für das Stylen einer Bildlaufleiste oder eine Lösung mit mehreren Datenvorlagen für einfache Aufgaben suchen.

MVVM basiert hauptsächlich auf dem von mir verwendeten UI-Framework. Bei so etwas wie WPF oder Silverlight, das ein Paradigma für die Bindung an einen Datenkontext hat, könnte dieser Datenkontext immer als Ansichtsmodell bezeichnet werden.

Die Frage für mich ist also, wann Sie eine große, separate Klasse erstellen, die das Ansichtsmodell für dieses Steuerelement / Fenster / diese Anwendung ist, und wann Sie die bereits erstellten Objekte nicht mehr verwenden können.

Wir haben also eine klassische Frage zum Hinzufügen einer Abstraktionsebene. Die VM fügt einem Projekt Gewicht, Trägheit und Struktur hinzu. Es wird es einfacher machen, davon aufzubauen, aber schwieriger zu ändern und länger zu bauen. Keines dieser Dinge ist leicht zu quantifizieren.

Für eine billige Antwort ist MVVM nicht für Befehlszeilenanwendungen oder Webdienste geeignet :)