Sollte Ihr ViewModel XAML-Elemente als Eigenschaften ausweisen oder nicht?

Question

Bei der StackOverflow-Frage Wie können WPF-Konverter in einem MVVM-Muster verwendet werden? Ich habe gelernt, dass Wertkonverter nicht im MVVM-Muster verwendet werden sollten, da die die Funktionalität eines Wertkonverters sollte vom ViewModel selbst übernommen werden .

Das macht Sinn.

Aber ich erinnere mich, gelesen zu haben, dass man keine XAML-Elemente in der Ansicht ausstellen sondern stellen nur Datensammlungen zur Verfügung, die die Ansicht dann mit Hilfe von DataTemplates bindet und anzeigt.

Konverter scheinen jedoch recht leistungsfähig zu sein (sie werden z. B. in der MVVM-Vorlage Demo (siehe das "Messenger Sample" nach dem Entpacken) in diesem sie können Objekte in Objekte umwandeln z. B. Nachrichtenobjekte in FlowDocument-Objekte oder Kundenobjekte in Sichtbarkeitsobjekte oder benutzerdefinierte Statusobjekte in Bilder usw.

Wenn also ein ViewModel zu die Funktionalität eines Wertkonverters übernehmen muss es XAML-Elemente und -Eigenschaften wie StackPanel, Visibility, Color, FlowDocument usw. bereitstellen, oder?

Sieht jemand einen Grund, warum ein ViewModel sollte nicht diese reichen XAML-Objekte wie Wertkonverter tun freizugeben?

Answer 1

Denn dann kann das ViewModel nur mit einer bestimmten visuellen Darstellung verwendet werden. Sobald das ViewModel XAML emittiert, wird der Designinhalt in die Domäne des Entwicklers verlagert. Das bedeutet, dass der Designer, der Expression Blend verwendet, keine Design-Assets bearbeiten kann - und der Workflow zwischen Designer und Entwickler ist unterbrochen. Wenn Sie die XAML auf der Seite belassen und Wertkonverter mit Datenvorlagen verwenden, bleibt das Design vom Code getrennt.

Wenn Ihr ViewModel spezifisches XAML offenlegt, schränkt es auch ein, dass das ViewModel nur in dieser spezifischen Instanz verwendet werden kann und macht es weniger wiederverwendbar.

Answer 2

Vergessen Sie nicht, dass Sie auch DataTemplates verwenden können. Ich kann einen gewissen Sinn darin sehen, ValueConverters aus MVVM herauszuhalten, aber bei DataTemplates geht es darum, Objekte in GUI zu transformieren.

Ihr ViewModel kann andere Objekte (z.B. verschachtelte ViewModels) der GUI zur Verfügung stellen, und die GUI kann mit <DataTemplate DataType="{x:Type SubViewModel}">... um diese Objekte auf die GUI abzubilden.

Answer 3

Sieht jemand einen Grund, warum ein ViewModel sollte nicht diese reichen XAML-Objekte wie Wertkonverter tun freizugeben?

Auf jeden Fall, denn es untergräbt alle Ziele von MVVM:

1. Sie sind nicht mehr unit-testbar, zumindest nicht einfach.
2. Die Trennung zwischen Logik (Ansichtsmodell) und Darstellung (Ansicht) ist nicht mehr gegeben. Daher können Designer und Entwickler nicht mehr so einfach zusammenarbeiten.
3. Die Wartung des Codes ist schwieriger, weil Sie die Anliegen miteinander vermischt haben.

Wenn ich ein View-Modell sehen würde, das einen View zurückgibt, würde ich es nicht einmal als MVVM klassifizieren.

Answer 4

Ich denke, eine Idee von mvvm/mvc/mvp usw. ist es, den GUI-Code in einer Datei/Klasse zu isolieren. Wenn Sie dies tun, können Sie auf einige andere UI ohne Neuschreiben der anderen Objekte ändern? Ich denke, wenn Sie WPF-spezifische Objekte weitergeben, lautet die Antwort nein. Es ist eine Wertentscheidung, die Sie für sich selbst machen müssen.

Answer 5

Es gibt keine hundertprozentige Regel, die für dieses oder viele andere Konzepte gilt, wenn man sie ohne die Perspektive diskutiert, warum sich die Meinung der Gemeinschaft in diese Richtung verschoben hat. Es gibt keine "angenommene" Wahrheit oder Wissenschaft in der "konventionellen Weisheit", unabhängig davon, wie neu oder überzeugend sie zu diesem Zeitpunkt ist.

Mit anderen Worten: Geben Sie einfach Ihr Bestes mit Ihrem Team, denn wenn Sie gut sind, werden Sie bereits durch menschliche Belange weit mehr in Mitleidenschaft gezogen als durch etwas so Reales wie dieses.