View and ViewModel wird zu groß

Question

Während ich in meiner Anwendung zusätzliche Funktionen zur Hauptansicht hinzugefügt habe, habe ich festgestellt, dass die Menge an Code bald ein Problem werden wird (derzeit etwa 600 Zeilen Code in meinem ViewModel und ich immer noch) habe viel hinzuzufügen).

Ich habe nach Artikeln darüber gesucht, wie Sie Ihre Ansicht in kleinere Komponenten aufteilen, aber ich habe keine befriedigende Lösung gefunden. Eine Person schlug vor, untergeordnete Ansichtsmodelle zu verwenden, die jedoch mit anderen Problemen konfrontiert waren (Abhängigkeit zwischen den Ansichtsmodellen).

Ich habe über die Verwendung von Benutzersteuerelementen gedacht, aber es gibt nichts auf der Ansicht, die ich auf anderen Ansichten verwende, so dass es den Zweck der Benutzersteuerelemente irgendwie besiegt.

Was ist eine korrekte Vorgehensweise in dieser Situation?

Danke, Adrian

Answer 1

Wenn Sie eine Ansicht in Einzelteile aufteilen möchten, dann müssen Sie Ansicht Zusammensetzung tun. Wenn Sie eine MVVM-App erstellen, geben Sie you should really be using an MVVM framework ein. Etwas wie Caliburn.Micro macht die Komposition unglaublich einfach.

Zwischen den Ansichtsmodellen müssen nicht unbedingt Abhängigkeiten bestehen, sie sollten nur wissen, was sie brauchen, um ihre Ansicht zu erzeugen. Dies könnte eine Teilmenge des Geschäftsobjekts sein, die das übergeordnete Ansichtsmodell enthält. Da das übergeordnete Ansichtsmodell Verweise auf alle untergeordneten Ansichtsmodelle enthält, kann es die relevanten Teile des Geschäftsobjekts zum Zeitpunkt der Erstellung an sie übergeben.

Answer 2

Ich stimme auch zu Caliburn.Micro ist eine gute Lösung für die Aufteilung Ihrer Anwendung in kleinere Komponenten. In Caliburn.Micro basiert die Kommunikation zwischen Viewmodels auf dem Event aggregator Muster.

Dies macht eine lose Kopplung zwischen Viewmodel

Answer 3

Ich würde bei der Verwendung von Caliburn Micro zustimmen.

Um Teufels Advokat zu spielen, können Sie Ihre ViewModel-Datei jedoch in separate Dateien (gleicher Klassenname) aufteilen und das Schlüsselwort partial vor dem Schlüsselwort class verwenden. Es ist in der Regel aufgeräumter und ein Schritt weg (nicht brechender Vorläufer) von der Zerlegung in getrennte Klassen.

Answer 4

Aufteilen ist nicht ideal.

Es sieht so aus, als ob sich das Caliburn-Toolkit auf Ereignisse konzentriert, während meine Anwendung größtenteils auf ICommand-Implementierungen beruht.

Für mich war die erste Begegnung mit Caliburn.Micro unbefriedigend. Das Setup schien auf VS2010 zugeschnitten zu sein - was für mich vielversprechend klang - weil ich VS2010 pro habe. Aber ich habe mich in den Setups von Silverlight verirrt. Im Vergleich zu Toolkits wie Prism fehlt die Leichtigkeit eines Starts. Es dauert jetzt zu viel Zeit, um jetzt zu wechseln. Ich benutze mein eigenes MVVM-Paradigma, es ist weniger abstrakt als das Caliburn, es integriert mehrsprachige Unterstützung überall, und es steht nur ein akzeptables Problem, dass einige Quellen aufgrund der Natur des Binding/DataContext-Paradigmas zu groß werden. Für dieses Problem akzeptiere ich, dass "partielle Klasse" eine Lösung ist - obwohl ich weiß, dass es eine elegantere Lösung gibt.

In der Hitze meiner Arbeit kann ich nicht zu einem anderen Toolkit wechseln.

Also warte ich sanft auf Microsoft, um mehr Flexibilität für dieses Binding/DataContext-Paradigma zu ermöglichen.

Es kann der Fall sein, dass Caliburn mehr Intelligenz zeigt, die einem Objekt ein Ansichtsmodell zuweist. Macht es ? (Ich denke, dass es tut.)

Was eine andere Option sein könnte, ist ein benutzerdefiniertes (xaml verwendbares) Objekt zu definieren, das einen benutzerdefinierten Zuordner auslöst, welches Steuerelement welchem ​​Ansichtsmodell zugewiesen werden soll. Wie ist es damit ?