MVVM: Wie Model und ViewModel synchron halten?

Hallo,

ich muß zugeben das meine MVVM-Begeisterung etwas nachgelassen hat und hoffe ihr könnt mir helfen 😃

Meine Applikation besteht aus einer Liste von Business-Objekten (Divisions), welche wiederum Listen enthalten usw. Also in etwa so:

    public class Division
    {
        public IList<Group> Groups { get; set; }
    }

    public class Group
    {
        public IList<Question> Questions { get; set; }
    }

    public class Question
    { }

Nun ist es ja notwendig in den jeweiligen ViewModels 2 Listen (jeweils des Models und des ViewModels) zu halten und zu synchronisieren. Ich finde das macht die ganze Sache sehr unübersichtlich und irgendwie schwer nachvollziehbar.

Nun meine Frage: Mein Model ist ja nun nicht so weit hergeholt und ich kann mir vorstellen das es dafür Design-Regeln gibt, welche ich mir mal anschauen könnte (Artikel / Projekt). Ich habe in anderen Projekten manchmal eine Repository-Klasse gesehen, welche jeweils um die Business-Klasse gebaut war. Geht das schon in die richtige Richtung?

Viele Grüße

Leider keine Antwort auf deine Frage, aber ich habe selbst ein Frage an dich. Brauchst du nicht ObservableCollections statt Listen? Der Clou bei MVVM ist doch auch das Handling der Propertychanges.

In diesem Zusammenhang hab ich selbst schon einige graue Haare von eigentlich trivalen Aufgaben bekommen (z.B. Sortierung und Filterung von Liste).

Hallo,
ich sehe die Businesslogik ganz unabhängig vom UI. Du baust Zugriffsmethoden wie: GetAllDivisions und GetDivision (id) AddGroup(division, group) usw.

Diese Businessmethoden greifen dann auf die Datenschicht zu. Dort sind die von dir beschriebenen Objekte definiert.

Und die UI:
Das xaml der UI ist mit Bindings auf das ViewModel verknüpft, welches entsprechend der Controls in der UI verschiedene Properties und Enumerables anbietet. Diese wiederum werden im Getter eine Abfrage der Businesslogik haben. Und im Setter die Methoden der Businesslogik zum Ändern der internen Objekte. Mit PropertyChanged()-Aufrufen, damit auch die anderen Properties im ViewModel aktuell gehalten werden und entsprechend in den Controls angezeigt werden.

Demo's hierfür gibts bestimmt überall. Wenn du fündig wirst kannst du ja mal einen schönen Link posten?

Hallo,

nein meiner Meinung nach (und ich hoffe ich liege damit nicht allzu falsch) brauche ich an dieser Stelle keine ObservableCollections da es sich hier um die Business-Logik (aka Model) handelt. Laut Definition braucht sich das Modell nicht darum kümmern ob eventuelle Gui's aktualisiert werden müssen oder nicht... dafür ist das ViewModel zuständig. Im Falle der ViewModel-Listen brauche ich dann die ObservableCollections.

Laut Definition braucht sich das Modell nicht darum kümmern ob eventuelle Gui's aktualisiert werden müssen oder nicht... dafür ist das ViewModel zuständig

Klar - so kann man das sehen.
Letztlich entwickelt man jedes Modell aber genau genommen zu dem Zweck, es dem User einmal darzustellen - dafür zahlt ja auch letztlich der Auftraggeber 😉

Insofern ist es unzweckmäßig, Models "blind" zu entwickeln d.h. sich an dieser Stelle keinerlei Gedanken zu machen, wie man später Daten synchronisiert.

Möglichkeiten hast du folgende:*Immutable Models: Da entfällt das Problem einfach 🙂

*Models, die ausschließlich über ihr ViewModel manipuliert werden. Ist z.B. bei datengetriebenen Anwendungen häufig problemlos möglich, wo der User hauptsächlich Daten ändert und ansieht (und die Modells sich aktiv nicht ändern). Zusätzlich kann das ViewModel nach jedem Methodenaufruf mit Seiteneffekten auf das Modell einfach alle Properties refreshen. Damit kann man schon einmal sehr viele Fälle abdecken.
INotifyPropertyChanged führt dann ein "ModelViewModel" (also ein ViewModel, das lediglich ein Model kapselt und von anderen ViewModels verwendet wird) ein.

*Models, die INotifyPropertyChanged implementieren: Die implementierungstechnisch einfachste Variante. Bei genauerem Überlegen hat man durch diese Vorgehensweise (insbesondere bei kleineren Anwedungen) am wenigsten Ärger - und designtechnisch ist INotifyPropertyChanged ja auch nichts UI-spezifisches; im Gegenteil: Das Event kann auch bei Modelspezifischem Code ganz hilfreich sein (z.B. Synchronisierung von Parent-Child Beziehungen etc.) *Models, die spezielle Events bereitstellen: Wenn du partout kein INotifyPropertyChanged in deinen Models haben willst, kannst du ja auch eine "abgespeckte" Variante davon implementieren: Stelle z.B. ein Changed Event (oder mehrere Events) bereit, die bei jeder Änderung ausgelöst werden.
Allerdings implementiert man dann IMHO besser gleich INotifyPropertyChanged .

Zudem ist es wunderbar möglich, diese Ansätze in einer Anwendung zu kombinieren - natürlich nicht willkürlich, sondern durchdacht 😉