MVVM: Thin Viewmodel und Rich-Modelle

Question

ich mit dem MVVM Muster zu kämpfen bin fort und bei dem Versuch, ein praktisches Design für kleines/mittleres Projekt zu erstellen, haben eine Reihe von Herausforderungen führen. Eine dieser Herausforderungen besteht darin, herauszufinden, wie man die Vorteile der Entkopplung mit diesem Muster nutzen kann, ohne viel repetitiven, schwer zu wartenden Code zu erstellen.

Meine aktuelle Strategie bestand darin, 'reiche' Modellklassen zu erstellen. Sie sind sich vollkommen bewusst, dass sie von einem MVVM-Muster konsumiert werden und implementieren INotifyPropertyChanged, lassen ihre Sammlungen beobachten und wissen, dass sie immer unter Beobachtung stehen. Meine ViewModel-Klassen sind in der Regel sehr dünn und weisen nur Eigenschaften zu, wenn Daten tatsächlich transformiert werden müssen, wobei der Großteil ihres Codes RelayCommand-Handler sind. Views binden sich glücklicherweise entweder direkt an ViewModels oder an Models, je nachdem, ob eine Datenumwandlung erforderlich ist oder nicht. Ich benutze AOP (über Postsharp), um den Schmerz von INotifyPropertyChanged zu lindern, so dass es einfach ist, alle meine Modellklassen auf diese Weise 'reich' zu machen.

Gibt es signifikante Nachteile bei der Verwendung dieses Ansatzes? Kann ich davon ausgehen, dass ViewModel und View so eng miteinander verbunden sind, dass ich, wenn ich eine neue Datenumwandlung für die View benötige, diese einfach zum ViewModel hinzufügen kann?

Answer 1

ich INotifyPropertyChanged auf Ihrem Modell denken, ist nur dann sinnvoll, wenn Sie es erwar gleichzeitig operiert werden von VM und externen „Kräfte“.

Ich bin persönlich ein Anhänger von POCO-Modellen. Wenn ich ein rahmenspezifisches Gerüst in mein Modell einbauen würde, würde ich mir Sorgen machen. Wenn Sie ein Ereignis in Ihre Modellklasse einfügen, müssen Sie sorgfältig mögliche Probleme mit dem Lebenszyklus, der Serialisierung, dem Speicher usw. Ihres Modells berücksichtigen. Was passiert beispielsweise, wenn Sie Ihr Objekt aus der Datenquelle wiederherstellen und alte INotifyPropertyChanged-Abonnements jetzt ungültig sind?

Ähnlich besseren Ort für ObservableCollection ist in der VM, die eine IEnumerable-Datenquelle verbrauchen kann, und Gegenwart der Ansicht nur ausgewählte oder Ad-hoc-Elemente gefiltert.

Answer 2

Ich halte dies für den pragmatische Ansatz sein - wir dieses Muster in der Vergangenheit erfolgreich verfolgt haben. Die grundlegende Prämisse bestand darin, direkt an ein Modell zu binden, das INotifyPropertyChanged für die meisten schreibgeschützten Daten implementiert, und dann dem Ansichtsmodell zusätzliche Eigenschaften hinzuzufügen, damit die Ansichtsspezifisches (wie von Ihnen vorgeschlagen) transformiert werden muss. Für nicht schreibgeschützte Eigenschaften fanden wir es am einfachsten, die ViewModel-Einträge zu erstellen (im Allgemeinen vom Typ String), da dies die clientseitige Validierung einfach im ViewModel hinzufügen kann.

Answer 3

Ich stimme zu, dass es eine enge Verbindung zwischen View und ViewModel geben wird. Dies kann jedoch teilweise durch den Einsatz von IValueConverters erleichtert werden, wann immer es möglich ist, Transformationen durchzuführen.

Ich versuche, meine Business-Logik in meinem Viewmodel zu halten. Außerdem verwende ich das Viewmodel, um die Form meines Modells so zu ändern, dass es der Ansicht entspricht, die die Ansicht erwarten würde.

Answer 4

Haftungsausschluss - Ich bin kein Experte -

Ich habe INotifyChanged auf meine Modelle nicht. Ich hatte dies zuerst getan, kam aber zu der einfachen Erkenntnis, dass INotifyChanged wirklich nur praktisch ist, um die Benutzeroberfläche zu benachrichtigen, sodass ich jetzt nur INotifyChanged auf meine ViewModels setze. Dies hat es einfacher gemacht, die Anzahl von "RaisePropertyChanged" zu steuern ... Meine Ansichten verweisen niemals direkt auf ein Modell.

ich an meinem ersten MVVM Projekt noch auf meinem dritten großen refactor gerade arbeite: jetzt P