it-swarm.com.de

Sollte ViewModel oder View in MVVM für das Erstellen neuer Ansichten verantwortlich sein?

In meiner WPF-Anwendung möchte ich eine neue Ansicht erstellen. Wo soll ich das machen - in ViewModel oder Model?

Die Anwendung ist ein (vorerst sehr einfaches) formularähnliches Tool mit einem Fenster und einer einzigen Schaltfläche "Senden". Wenn eines der Kontrollkästchen aktiviert ist, sollte ein neues Fenster mit demselben ViewModel angezeigt werden, in dem der Benutzer nach zusätzlichen Details gefragt wird. Für die Zwecke dieser Frage betrachten wir nur den neuen Fensteransatz, ohne andere Ansätze wie das gezeigte/ausgeblendete Panel zu berücksichtigen.

Im Idealfall sollte in View kein Code vorhanden sein. Da View keine Logik enthält VM müsste zunächst prüfen, ob eine neue Ansicht erstellt werden muss, und - wenn dies der Fall ist - diese Verantwortung an View zurückgeben, was zu Code führt aufblähen.

Andererseits verstößt das Erstellen einer neuen Ansicht in ViewModel gegen das Prinzip, dass ViewModel nichts über View wissen sollte.

Also, ist es besser, neue Ansichten in View oder ViewModel zu erstellen?

11
Mac70

Ich verwende die Abhängigkeitsinjektion und ein IViewFactory, das in das Ansichtsmodell injiziert wird, um beide Einschränkungen zu berücksichtigen.

Ein ProductViewModel (zum Beispiel) ruft this.viewFactory.Show("Details", this) auf, um ProductDetailsView mit sich selbst als ProductViewModel zu öffnen. Es könnte auch eine Ansicht basierend auf einem anderen Ansichtsmodell mit this.viewFactory.Show<ClientViewModel>() öffnen.

Die Implementierung (es gibt tatsächlich mehrere für WinForms, einfaches Wpf-Windows, eine Wpf-Shell mit Registerkarten, ...) basiert auf einer StructureMap-Konvention. Die Ansichten bezeichnen ihr Ansichtsmodell über ein IView<ProductViewModel> Schnittstelle.

Das Ansichtsmodell weiß also nichts über die Ansicht außer ihrer Rolle (Standardansicht, Detailansicht, ...), und die Ansicht enthält keinen Code zum Erstellen einer anderen Ansicht. Außerdem befinden sich die Ansichtsmodelle in einer separaten Assembly, die auf keine Wpf-Assembly verweist.

8
Philippe

Theoretische Antwort

Wenn Sie ein ViewModel haben, sind Aktionen mit kosmetischen Effekten (z. B. Hervorheben eines Elements beim Mouseover) Aufgabe des View, während Aktionen mit "echten" Effekten (z. B. Erstellen eines neuen Fensters) ) sind die Aufgabe des ViewModel.

Das Erstellen eines neuen Fensters ist daher ein Job für ViewModel. Weder die Ansicht noch die ViewModel sollten jedoch genau wissen, wie ein Fenster erstellt wird. Dies gehört nicht zu ihren Verantwortlichkeiten und gehört zu einer anderen Klasse.

Sie könnten argumentieren, dass das Erstellen eines neuen Fensters ein Job für View ist. Obwohl ich nicht zustimmen würde, ist eine solche Debatte wenig wertvoll, da es in der Praxis nicht das Ende der Welt ist, wenn Sie diesen Code in View einfügen, und es auch nicht viel Arbeit ist, ihn zu verschieben zu einem späteren Zeitpunkt zum ViewModel. Der wichtige Teil ist, dass die Logik zum Erstellen eines neuen Fensters in einer unabhängigen Klasse enthalten ist, normalerweise einer Art WindowFactory. Der Punkt von MVVM, MVP, MVC usw. ist, dass Sie Klassen mit wenigen und genau definierten Verantwortlichkeiten haben. Aus diesem Grund fügen Sie dem View, ViewModel oder Model keine zusätzlichen Verantwortlichkeiten hinzu, wenn Sie dies nicht benötigen.

Unter keinen Umständen gehört die Erstellung des Fensters zum Model, da dem Model nicht einmal bewusst ist, dass es so etwas wie eine GUI gibt.

Praktische Antwort

Hierbei handelt es sich um ein "formularähnliches Ein-Fenster-Tool mit einer einzigen" Senden "-Schaltfläche" . Hier ist also ein schamloser Plug für eine verwandte Antwort von mir: Warum MVVM verwenden?

Um zusammenzufassen, was diese Antwort sagt: Halten Sie es einfach. Oh, und denken Sie an die oben genannte theoretische Antwort, um sie zu implementieren, sobald Ihr Fenster mit einer einzelnen Schaltfläche komplexer wird.

7
Peter