MVVM: ViewModel: Typ von Listen = Model oder auch ViewModel?

Hallo,

Mal wieder eine Prinzip-Frage...
Ich sehe in MVVM Tutorials oft zwei unterschiedliche Herangehensweisen, wenn ein ViewModel eine Liste mit komplexen (eigenen) Datentypen enthält.
Angenommen meine Model-Klasse A enthält eine Liste mit Objekten der Klassen B.
Ich hätte dann auf jeden Fall ein ViewModel Vm_A und darin bräuchte ich auch in irgendeiner Form eine Liste der Objekte der Klasse B.
Wenn man das Prinzip "das View kennt kein Model" wörtlich nimmt und streng durchzieht, müsste ich nun in meinem Vm_A eine ObservableCollection anbieten, die Objekte von Vm_B enthält.
Ich sehe aber oft, dass an dieser Stelle mit dem Model selber gearbeitet wird. Mein Vm_A bietet also eine Liste mit Objekten der Klasse B an (die Liste wird quasi einfach nur 1:1 aus dem Model selbst hochgereicht und nicht selbst in ein ViewModel gepackt).
Man sieht solchen Tutorials leider meist nicht an (auch nicht von den Bewertungen her, denn ein WPF-Anfänger frisst oft alles (und bewertet es gut) was ihm hingeworfen wird, hauptsache es funktioniert), ob der Urheber sich technisch echt auskennt oder einfach nur was zusammengebastelt hat.
Und wie gesagt...man sieht beide Varianten, ungefähr gleich oft würde ich sagen, meist mit sehr ähnlichen, einfachen Beispielen.

Wie macht man es richtig bzw. wie machen es die WPF Gurus hier?
Ich habe mir überlegt, dass es hier vielleicht auch wieder (wie so oft) vom Kontext abhängt...wenn ich die Objekte von B z.B. wirklich nur als Auswahl anzeigen will oder so, hätte ich ja in den meisten Fällen keinen Mehrwert, sie in einem eigenen ViewModel zu verpacken. Nur wenn ich mit dem Objekt von B auch etwas komplexeres vorhabe (z.B: auch editieren, komplexe Daten anzeigen etc.), würde ein eigenes ViewModel Vorteile bringen...???

gruß & danke schonmal für eure Gedanken dazu
sth_Weird

Wie immer gibt es hier nicht den einen Weg.

Natürlich sollte ein View nicht mit dem Model arbeiten, aber es gilt auch KISS.

Wenn du also ( wie du selber sagst ) die Liste nur anzeigst, kann durchaus das Model auch das ViewModel sein.
Auf der anderen Seite ist so gaaanz schnell alles durcheinander.

Ich nehme dann lieber MicroModels .
Hatte mal eine Version gemacht in der ich die Collections readonly hatte.

Ich schlage mich gerade mit ähnlichen Problemen rum und habe dafür auch noch kein Patentrezept gefunden.
Die Frage ist hier mMn auch, ob man sich im ViewModel eher an der View oder eher am Model orientiert. Beim ersteren gibt es für alle UI-Elemente der View eine Entsprechung im ViewModel, also z.B. Properties für Input-UI-Elemente, Commands für Buttons, etc. Beim letzteren sollte das ViewModel das Model in eine Databinding-taugliche Form bringen. Im Idealfall sollte man das unter einen Hut bringen können, aber damit tue ich mich im Moment noch schwer.

Ich bin da auch für jeden Tipp dankbar, auch gerade für Empfehlungen von wirklich guten Tutorials. Die meisten Tutorials erklären meist nur die Basics und das anhand von ganz einfach gehaltenen Beispielen, die in der "realen Welt" meist nicht in so einfacher Form vorkommen.

Die Frage ist hier mMn auch, ob man sich im ViewModel eher an der View oder eher am Model orientiert. Beim ersteren gibt es für alle UI-Elemente der View eine Entsprechung im ViewModel, also z.B. Properties für Input-UI-Elemente, Commands für Buttons, etc. Beim letzteren sollte das ViewModel das Model in eine Databinding-taugliche Form bringen.

Sehe ich ganz anders, aber diese Discussion hatten wir hier vor Jahren auch schon mal.

Wenn man pro Model nur ein ViewModel macht, da es alles "nur" Bindbar macht, kann man damit bei weitem nicht alles abbilden was man machen will.

WPF wurde unter anderem mal entwickelt um Designer und Programmierer am gleichen "Fenster" arbeiten lasen zu können.
Hierzu soll der Designer das VM bekommen und damit dann die UI erstellen.
Wenn er aber alles machen kann, ist das eher nicht zielführend.

Das ViewModel ist ein bindbarer Controler und ist die Businesslogik des Views.
Also sollte man pro View ein ViewModel machen.
Das man mit Vererbung ggf auch Arbeit sparen kann ist dabei unbelassen.

Ein guter Hinweis das das auch die allgemein akzeptierte Herangehensweise ist das eigentlich alle MVVM Toolkits ihre ViewModels am namen erkennen, der sich vom View nur durch Model unterscheidet, also MainView zu MainModel.

Und ehrlich gesagt, mit diesen MVVM Bibliotheken, egal ob Chinch, MVVMLight, Caliburn.Micro oder wie sie auch alle heißen, ist das wirklich kaum Aufwand.

Das meiste ist doch eh Validerung oder Datenverwaltung die wieder von anderen Teilen erledigt werden.