it-swarm-eu.dev

Unter welchen Bedingungen ist die Verwendung von MVVM angemessen?

Modellansicht View-Model wurde von Microsoft entwickelt, um auf UI-Entwicklungsplattformen abzuzielen, die ereignisgesteuerte Programmierung unterstützen, insbesondere Windows Presentation Foundation (WPF) und Silverlight auf den .NET-Plattformen unter Verwendung von XAML- und .NET-Sprachen. In den letzten Jahren haben viele Javascript-Frameworks wie Angular, Knockout und ExtJS das Muster übernommen.

enter image description here

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

47
Kelly Sommers

MVVM soll verwendet werden, wenn komplexe Benutzerinteraktionen mit High-Fidelity-Benutzeroberflächen erforderlich sind (dh [~ # ~] wpf [~ # ~) ] ).

MVVM richtet sich an moderne UI-Entwicklungsplattformen (Windows Presentation Foundation oder WPF und Silverlight), bei denen es einen User Experience-Entwickler (UXi) gibt, dessen Anforderungen sich von denen eines eher „traditionellen“ Entwicklers unterscheiden (z. B. orientiert an Geschäftslogik und Backend-Entwicklung). Das View-Modell von MVVM ist „im Grunde ein Wertekonverter für Steroide“, was bedeutet, dass das View-Modell 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 die gesamte Anzeigelogik der Ansicht.

MVVM wurde entwickelt, um bestimmte Funktionen in WPF zu nutzen, um die Trennung der Entwicklung der Ansichtsebene vom Rest des Musters besser zu erleichtern, indem praktisch alle „Code-Behinds“ aus der Ansichtsebene entfernt werden. Anstatt Interactive Designer zum Schreiben von View-Code zu verpflichten, können sie die native WPF-Markup-Sprache XAML verwenden und Bindungen zum ViewModel erstellen, das von Anwendungsentwicklern geschrieben und verwaltet wird. Diese Rollentrennung ermöglicht es Interactive Designers, sich auf UX-Anforderungen anstatt auf Programmierung oder Geschäftslogik zu konzentrieren, sodass die Ebenen einer Anwendung in mehreren Arbeitsabläufen entwickelt werden können.

Für Benutzeroberflächen, in denen diese Art von umfangreicher 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 Code-Behind ausreichend.

19
Robert Harvey

Manchmal kann MVVM eine Falle sein. Nach meiner Erfahrung werden CRUD-ähnliche Anwendungen (Formulare gegenüber Daten) gegenüber eher aufgabenorientierten 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 "DDD Light" -Architektur gesehen. Ich weiß nicht genau warum, vielleicht weil die Bindung so einfach ist und es sehr einfach ist, eine Anwendung mit einem ORM und MVVM/Binding unter Verwendung von POCO/Anemic-Domänenobjekten einzurichten.

15
MatthieuGD

MVVM ist ein Pflaster für schlecht gestaltete Datenbindungsschichten. Insbesondere in der WPF/silverlight/WP7-Welt wurde es aufgrund von Einschränkungen bei der Datenbindung in WPF/XAML häufig verwendet.

Von nun an gehe ich davon aus, dass es sich um WPF/XAML handelt, da dies die Dinge klarer machen wird. Schauen wir uns einige der Mängel an, die MVVM in WPF/XAML beheben möchte.

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 sind. Diese C # -Objekte sind normalerweise über DataContext-Eigenschaften von Präsentationsobjekten mit XAML verbunden.

Daher muss das Ansichtsmodell-Objektdiagramm dem Präsentationsobjektdiagramm Ihrer Anwendung zugeordnet werden. Das heißt nicht, dass die Zuordnung eins zu eins sein muss, aber wenn 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 einer zusätzlichen Ansichtsmodell-Ebene, die erstellt und verwaltet werden muss.

Wenn ich einige Daten von Bildschirm A nach Bildschirm B verschieben möchte, muss ich mit Ansichtsmodellen herumspielen. Für einen Geschäftsmann ist dies eine Änderung 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 einiges an Datenumleitung erforderlich sein, um diese Änderung durchzuführen.

m nicht ausdrucksstarke Datenbindung umgehen

WPF/XAML-Bindungen sind nicht ausreichend aussagekräftig. Grundsätzlich können Sie eine Möglichkeit bereitstellen, zu einem Objekt zu gelangen, einen Eigenschaftspfad zu durchlaufen und Konverter zu binden, 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 true/false Visible/Collapsed gemacht hat. Viele WPF-Apps haben auch einen sogenannten NegatingVisibilityConverter oder ähnliches, der die Polarität umdreht. Dies sollte Alarmglocken auslösen.

MVVM bietet Ihnen Richtlinien für die Strukturierung Ihres C # -Codes, mit denen Sie diese Einschränkung beseitigen können. 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 selbst zu einem Angestellten gemacht - jetzt müssen Sie Bindungen an zwei Stellen (der Benutzeroberfläche und dem Code in C #) verfügbar machen und aktualisieren, wenn sich Ihre Benutzeroberfläche weiterentwickelt. Wenn Sie dieselbe Schaltfläche benötigen, um sich auf einem anderen Bildschirm zu befinden, müssen Sie eine ähnliche Eigenschaft in einem Ansichtsmodell verfügbar machen, auf das dieser Bildschirm zugreifen kann. Schlimmer noch, ich kann nicht einfach auf die XAML schauen und sehen, wann die Schaltfläche nicht mehr sichtbar ist. Sobald Bindungen etwas untrivial werden, muss ich Detektivarbeit im C # -Code leisten.

Der Zugriff auf Daten ist aggressiv

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

Die Idee des "aktuell angemeldeten Benutzers" ist ein gutes Beispiel - dies ist oft eine wirklich globale Sache innerhalb 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 jeder DataContext mir eine Möglichkeit gibt, zum aktuellen Benutzerobjekt zu gelangen. MVVM kann dies aufnehmen, aber die Ansichtsmodelle werden ein Chaos sein, da alle Zugriff auf diese globalen Daten gewähren müssen.

Ein Beispiel, bei dem MVVM umfällt

Angenommen, wir haben eine Benutzerliste. Neben jedem Benutzer möchten wir die Schaltfläche "Benutzer löschen" anzeigen, 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 nur 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 eine Eigenschaft namens "DeleteButtonVisibility" oder "CanDelete" für dieses Ansichtsmodellobjekt verfügbar machen sollten (abhängig von Ihren Gefühlen über Bindungskonverter).

Dieses Objekt wird auf die meisten anderen Arten einem Benutzerobjekt sehr ähnlich sehen - es muss möglicherweise alle Eigenschaften des Benutzermodellobjekts widerspiegeln und Aktualisierungen an diese Daten weiterleiten, wenn es sich ändert. Das fühlt sich wirklich schwierig an - MVVM macht Sie wieder zu einem Angestellten, indem es Sie zwingt, dieses benutzerähnliche Objekt zu pflegen.

Bedenken Sie, dass Sie wahrscheinlich auch die Eigenschaften Ihres Benutzers in einer Datenbank, dem Modell und der Ansicht darstellen müssen. Wenn Sie eine API zwischen sich und Ihrer Datenbank haben, ist es schlimmer - sie werden 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. Oft werden dieselben Daten an vielen Stellen und in Ihrer Benutzeroberfläche dargestellt - dies fügt nicht nur eine Ebene hinzu, sondern auch 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 ist global für alle XAML in meiner App verfügbar. ID würde auf eine Eigenschaft im DataContext für meine Listenzeile verweisen. Die Sichtbarkeit wird automatisch vom Booleschen Wert konvertiert. Alle Aktualisierungen von Id, CurrentUser.IsAdmin, CurrentUser oder CurrentUser.Id würden eine Aktualisierung der Sichtbarkeit dieser Schaltfläche auslösen. 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. Lassen Sie sich nicht täuschen - es gehört nicht zur selben 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.).

Fazit

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 im obigen Beispiel "Wie die Dinge hätten sein können" dargestellt wird - Modell, das direkt der Ansicht ausgesetzt ist, mit komplexen Datenbindungsausdrücken und flexiblen Wertezwängen. Es ist viel besser - lesbarer, beschreibbarer und wartbarer.

MVVM fordert Sie auf, Ihren Code ausführlicher und weniger wartbar zu strukturieren.

Erstellen Sie anstelle von MVVM einige Dinge, die Ihnen dabei helfen, die gute Erfahrung zu approximieren: Entwickeln Sie eine Konvention, um den globalen Status Ihrer Benutzeroberfläche konsistent zugänglich zu machen. Erstellen Sie einige Tools aus Bindungskonvertern, MultiBinding usw., mit denen Sie komplexere Bindungsausdrücke ausdrücken können. Bauen Sie sich eine Bibliothek mit Bindungskonvertern auf, um häufige Fälle von Zwang weniger schmerzhaft zu machen.

Noch besser - ersetzen Sie XAML durch etwas Ausdrucksvolleres. XAML ist ein sehr einfaches XML-Format zum Instanziieren von C # -Objekten - es wäre nicht schwer, eine ausdrucksstärkere Variante 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 Mist wie MVVM treiben, anstatt sich auf Ihre Problemdomäne zu konzentrieren.

13
blucz

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

  1. Für Anwendungen oder Spiele, die viel UI-/Interaktionscode erfordern, um viele benutzerdefinierte Verhaltensweisen hinzuzufügen und gleichzeitig die Leistung aufrechtzuerhalten - es ist oft besser, ein bisschen schmutziges MVVM zu verwenden - verwenden Sie es, wenn es nützlich ist oder datenorientierter ist als Interaktionszentrierte Bereiche des Codes. Angenommen, Sie möchten ein Steuerelement erstellen und zwischen verschiedenen übergeordneten Steuerelementen verschieben oder auf andere Weise zwischenspeichern ...

  2. Es hat eine ziemlich steile Lernkurve. Wenn Sie also keine Zeit haben, planen Sie, viel in WPF/SL zu entwickeln, Designer in Blend zu haben, das Bedürfnis haben, Testcode für Ihre Benutzeroberfläche zu schreiben, oder auf andere Weise jahrelange Wartungsarbeiten für Ihre Benutzeroberfläche erwarten 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 auf diese Weise die wichtigsten Fehler gefunden werden, 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 und dann 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 Seien Sie aufgrund der Lizenzierung problematisch. Erstellen Sie eine Sippets-Bibliothek, um effizient zu codieren. Stellen Sie jedoch fest, dass die Plattform nicht immer gut mit Bindungen funktioniert und eine Bibliothek mit Verhaltensweisen erstellen muss, die Ihnen das bieten, was Sie benötigen.

Insgesamt - wenn Sie alle Hürden überwinden und das Muster ziemlich gut beherrschen - zahlt sich alles in Klarheit, Wartbarkeit und ... Prahlereirechten aus? :) :)

8
Filip Skakun

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 kostet und Geld kostet. Mit streng meine ich Regeln wie "kein Code dahinter".

Es ist in nichts anderem als der grundlegendsten 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 von benutzerdefinierten Steuerelementen erstellen oder vorhandene Steuerelemente umschließen, um das Interaktionsparadigma bei der Arbeit mit MVVM zu unterstützen.

Ich habe alle Arten von Swish-UI-Steuerelementen mit 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 eine Reihe von Steuerelementen verpackt, was diesen Code-Behind irgendwie in Ordnung macht.

Es ist oft einfacher, einfach den Code-Behind und das clevere UI-Zeug in die Ansicht zu schreiben, anstatt nur zu diesem Zweck eine Reihe von Steuerelementen aufzubauen.

Das Ziel von MVVM ist es, die Anwendungs-/Geschäftslogik von der UI-Logik zu trennen. Das Bindungssystem und MVVM sind eine gute Möglichkeit, dies zu tun.

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

Die Möglichkeit, eine Benutzeroberfläche schnell neu zu gestalten, 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, damit die Kopplung enger ist, als Sie vielleicht denken.

Für mich verwende ich MVVM, um meine Anwendungslogik getrennt zu halten (normalerweise verwende ich einen testbaren Controller und eine Reihe von logiklosen Ansichtsmodellen), aber was auch immer Code und Tricks erforderlich sind, damit meine Benutzeroberfläche sexy aussieht und sich sexy verhält, tue ich nicht Schwitzen.

Andernfalls regieren Sie Ihre Designs, coolen Animationen usw., nur weil die Idee, wie Sie alles mit MVVM realisieren können, zu umwerfend wird.

MVVM hat, wie die meisten Dinge im Leben, irgendwo 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.

8
Luke Puplett

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

MVVM ist derzeit 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 nicht verbundene ViewModels 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 Modell 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, besteht darin, dass Sie eine Technologie von Drittanbietern integrieren müssen, 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 etwas wie Win Forms in Ihre WPF-Lösung mischen und anpassen, 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.

7
Pete O'Hanlon

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 wirklich vorstellen, warum Sie MVVM bei der Arbeit mit WPF/Silverlight NICHT verwenden würden, 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 bei 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, führen Sie tatsächlich eine ViewModel-Methode aus. 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 den Anforderungen ab. Als ich einmal eine kleine App ohne MVVM erstellt habe, habe ich es am Ende bereut (sie wurde später überarbeitet, um MVVM beim Hinzufügen eines Updates zu verwenden).

4
Rachel

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 fehlerhaft sein oder Blend zum Absturz bringen, was den Designern Probleme bereitete.

Ich habe mich mit RoR beschäftigt und so ziemlich alles mit ASP.NET Webforms ü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 Codecampserver als Referenz verwendet habe . 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 bei Menschen, die das Erlernen von MVVM aufgeben.

Ich begann mit dem exzellenten MVVM-Light , das mir half, das Muster besser zu verstehen. Ich begann später mit Caliburn Micro zu arbeiten und dann gingen die Lichter an. Für mich ist Caliburn Micro wie die Verwendung von ASP.NET MVC über ASP.NET Webforms. Selbst für kleine Beispielanwendungen erstelle ich das Projekt NuGet CM und bin unterwegs. Ich folge dem ersten Ansatz von ViewModel und halte meine Ansichten in Blend dumm und einfach zu bearbeiten. Meine VMs sind testbar, wenn Sie sich damit auskennen, und mit CM ist es ziemlich einfach, komplexe Bildschirmlayouts zu umgehen.

3
Derek Beattie

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

WPF Composites

http://wpfcomposites.codeplex.com/

Hier wird ein prägnantes C # -Code-Behind für WPF erstellt, indem eine einfache Matrix über gitterbasierte Verbundwerkstoffe über die Benutzeroberfläche gelegt wird. Wenn eine moderne XAML-Benutzeroberfläche nur wenige Textbeschriftungen und eine Liste mit Fotos enthält, warum kann dies nicht durch die einfache Codezeile definiert werden: grid.AddText (guid, x-Koordinate, y-Koordinate)? Beachten Sie, dass dies nicht auf einer Leinwand ist, sondern sich immer noch in den WPF-Containern befindet: Raster, Dockpanel usw. WPF ist äußerst 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 Datenübertragungsobjekten (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, erweitert sich jedoch auf alle zusammengesetzten WPF-Steuerelemente. Beispielsweise ist jedes Listenfeld ein Verbund, der mit einem GUID (ein Verbund verbindet eins zu eins mit einer Klasse) hinzugefügt wird. Innerhalb dieses Elements befindet sich dann ein Raster, auf dem untergeordnete Benutzeroberflächenelemente ( Kinder, die eins zu eins an Eigenschaften in einer Klasse gebunden sind, können nach Belieben über Code-Behind hinzugefügt werden. Kinder können Textblöcke oder Bilder sein.

Die Idee ist, Indizes und eine gut definierte UI-Elementstruktur (sie erzwingt eine ListBox mit PresentationFramework.Aero-Thema als Basis) anstelle von Datenvorlagen zu nutzen. Dieser neue Ansatz schränkt absichtlich ein, was getan werden kann, liefert jedoch auf diese Weise einen präzisen, robusten C # -Code-Behind, der intuitiv ist. Sie müssen nicht nach Steuerungsvorlagenlösungen für die Gestaltung einer Bildlaufleiste suchen oder eine Lösung mit mehreren Datenvorlagen für einfache Aufgaben überladen.

2
WPF Developer