Hallo zusammen,

ich habe eine kurze Frage zu dem Model View ViewModel Ansatz. Die Grundidee dahinter verstehe ich, jedoch frage ich mich in wie weit das strikte einhalten dieses Ansatzes sinnvoll ist.
Wenn ich eine komplett neue Anwendung implementiere und sämtliche Eigenschaften des Models über den View steuern möchte, erzeuge ich letztendlich ein ViewModel, der nix anderes macht als jede Variable des Models neu zu deklarieren und die PropertyChanged-Events zwischen View und Model wieter zu reichen.

Wenn man auf einem alten Model aufbaut oder einige Parameter für einige Views ausblenden, sperren oder ergänzen möchte, macht es ja sinn - aber wenn ich es eins zu eins übernehme ist es ja eigentlich nur schreibarbeit? Sollte man es an diesen Stellen fest einhalten oder nur ViewModels erzeugen wenn es auch einen unterschied zum Model gibt?

Außerdem frage ich mich wie die abhängigkeiten verschiedener Models und ViewModels am elegantesten gelöst werden sollten: Wenn ich z.B. einen Datensatz aus der Datenbank lade erzeuge ich hieraus zunächst immer ein Model A. Dieses Objekt A kann dann ja z.B. eine List<Model B> enthalten. Für den View erzeuge ich ja aus Objekt A ein ViewModel VA und muss dann aus jedem in A enthaltene Model ein ViewModel generieren?

So mache ich es zumind. zur Zeit - das ist relativ viel schreibarbeit und daher frage ich mich, ob dies der richtige/eleganteste Ansatz ist?

Vielen Dank für eure Hilfe
Määx

Moderiert von Th69: Titel geändert: Paradikma -> Paradigma

Hallo Määx,

das ist generell schwierig zu beantworten und sollte man im Einzelfall überlegen, ob der Aufwand für ein ViewModel sich wirklich lohnt, vorallendingen wenn das Modell selbst schon die nötigen Fähigkeiten (INotifyPropertyChanged bzw. INotifyCollectionChanged (z.B. mittels einer ObservableCollection)) mitbringt.

Jede Abstraktionsebene macht es jedoch leichter, einzelne Komponenten zu erweitern oder sogar auszutauschen.

Falls der Aufwand für das händische Anlegen von Eigenschaften mit PropertyChanged()-Aufrufen zu groß ist, so kann man auch auf Hilfsmittel wie
YAPPI (Yet Another Property Proxy Implementation)
Kind Of Magic
NotifyPropertyWeaver
Castle Dynamic Proxy
Automatic Implementation of INotifyPropertyChanged on POCO Objects
zurückgreifen (s.a. Implementing INotifyPropertyChanged - does a better way exist?).

Den WPF Teil kenne ich nicht genau genug um da konkret was zu zu sagen (ob man den MVVM Unterbau auch sinnvoll weglassen kann etc.) aber allgemein benutzt man Muster wie MVVM insbesondere auch um sich auf unvorhersehbare Änderung (neu Anforderungen etc. weitere UI zum Beispiel fürs Web mit dem selben Model) vorzubereiten. Das heißt dann möglichst wenig Aufwand zu haben wenn sich die Anforderungen ändern und nicht bei der ersten Erstellung irgendeiner UI.

Wenn du dein Model schon in einer Form ist so das es für die UI passt, und nicht so das es das Problem möglichst allgemein UI unabhängig kapselt, und erst das ViewModel so das es für diese konkrete UI richtig ist, ja dann ist der Ausgangslage schon falsch denn eine UI Änderung führt dann mit hoher Wahrscheinlichkeit zwangsweise zu Änderungen des Modells und umgekehrt. Dann ist es vermutlich sinnfrei noch ein ViewModel zu haben das das Model einfach nur nochmal veröffentlicht. Das wäre dann einfach nur doppelter Aufwand beim erstellen und bei späterer Wartung.