MVVM: Was kommt ins Model was ins ViewModel

Hall zusammen.

Verwende das MVVM Muster für mein WPF Projekt. Eine Sache bereitet mir dabei immer etwas Kopfzerbrechen. Was kommt den nun ins Model was ins ViewModel. Also ein Beispiel.

Ich habe eine View in der ich verschiedene Daten aus einer Datenbank anzeigen will. Die Daten sind Rezepte.

Ist nun ein Rezept ein Model? Und das ViewModel enthält eine Liste von mehreren Models also Rezepten. Oder beinhaltet ein Model schon die Liste der Rezepte?

Und wer lädt die Daten aus der DB das Model oder das ViewModel?

Also wir handlen das in jedem Projekt immer ein bisschen anders aber ich beziehe das jetzt mal auf unser größtes Projekt wo es eigentlich am saubersten umgesetzt ist.
Wir haben ebenfalls eine Datenbank mit ca 70 Tabellen, ebenso vielen Views und um die 30 Prozeduren und arbeiten mit dem EntityFramework. Alles was irgendwie automatisch aus der Datenbank generiert wird, landet im Model(und dann auch in einer externen DLL).
Da das EF aber performancetechnisch nicht das allerbeste ist, haben wir im Model auch viele Klassen implementiert, die wir mittels ExecuteStoreQuery mappen und dann daraus List<T>en erstellen lassen. Im VM instanziieren wir dann unseren ObjectContext, filtern, kümmern uns um Updates aus der Datenbank und stellen die Daten der View zur Verfügung.

Ich glaube das wars soweit

Dravere

DB <-> Model <-> ViewModel <-> View

Grundsätzlich funktioniert die Zusammenarbeit so. Das ViewModel dient dazu, das Model aufzupeppen und für die View aufzubereiten. Model bildet somit die Daten in der Datenbank ab und das ViewModel die Daten in der View.

Zusätzliche Informationen findest du hier:
http://msdn.microsoft.com/en-us/library/gg430857.aspx
http://msdn.microsoft.com/en-us/library/gg430869.aspx

Grüssli

Schön. Wie das Muster allgemein funktioniert und was man alles machen kann weiß ich.

Vieleicht erst mal nur eine Frage:

Wer lädt die Daten aus der DB?

Firefighter

OrginellerName schrieb:

Schön. Wie das Muster allgemein funktioniert und was man alles machen kann weiß ich.

Vieleicht erst mal nur eine Frage:

Wer lädt die Daten aus der DB?

Der Controller der manchmal noch zwischen Model und DB haengt.

Hmm...das kommt jetzt so ein bisschen drauf an. Es gibt hier keine Vorschriften oder so aber wenn du das EF nutzt, dann stellt die eigentliche Datenbankverbindung das EF her. Wir haben uns aber angewöhnt, dass im VM zu machen da bei uns noch sehr viel Logik dranhängt die wiederum direkt mit der Oberfläche zusammenhängt. Man läuft leider sehr schnell Gefahr dass Spaghetti Code entsteht.

Ja ich verwende das EF. Und ja klar stellt das EF die Verbindung her.
Aber Daten selektieren muss ja auch jemand machen. Wer ist der aktive Part.

Also das Viewmodel.

Dravere

Wie schon gesagt wurde, es gibt nicht DIE LÖSUNG (tm)

Das ViewModel behandelt Events aus der View (meistens über Objekte, welche das ICommand -Interface implementieren, z.B. ein RelayCommand oder dergleichen). Heisst somit auch, dass das ViewModel die Anfrage an die DB startet. Welche/wieviele Layer nun zwischen dem ViewModel und der DB liegen, ist dir überlassen. Du kannst z.B. gleich ein "Unit Of Work"-Pattern vom Entity Framework im ViewModel verwenden.

Auch sollte hoffentlich klar sein, dass du viele ViewModel haben kannst. Heisst gewisse greifen auf die DB über z.B. das EF zu, andere dagegen bereiten Daten nur auf und werden z.B. von anderen ViewModels verwaltet.

Du darfst auch in gewissen Fällen ein Model nehmen und es als ViewModel einsetzen. Ist schlussendlich dir überlassen.

Grüssli

Ok. Danke mal.

Das gibt nur Probleme wenn man sowas wie Datenbank- oder Webservice Anfragen aus dem ViewModel startet. Dadurch bekommt das ViewModel zu viele Abhängigkeiten. ViewModels sollten meiner Meinung nach dumm wie Brot sein.
Die ViewModels können Events bereitstellen, wo sich dann übergeordnete Objekte registrieren und die Abfragen starten und das Ergebnis bei den ViewModels setzen.

Das heißt die Objekte die die Events abfangen, füllen dann die Listen im ViewModel. Oder im Model?

asc

OrginellerName schrieb:

Das heißt die Objekte die die Events abfangen, füllen dann die Listen im ViewModel. Oder im Model?

Die Frage ist hier wohl: Welche Abhängigkeiten akzeptiert man, und welche kann man aufbrechen.

Ich persönlich ziehe den Ansatz vor das die Aufrufrichtung immer von einem höheren (Näher am Benutzer) zu einem niedrigeren (Näher an einer Datenquelle) Layer geht [Oder mittels "Callbacks" (Seien es nun registrierte Schnittstellen, Eventhandler...) die Abhängigkeit umgedreht wird, ohne Detail preis zu geben], dabei aber Abhängigkeiten auch hinter austauschbaren Schnittstellen verborgen werden.

Sprich: Ich selbst habe kein Problem damit das ein ViewModel die Daten abruft, doch würde ich hier das ganze hinter einer Schnittstelle verbergen die ich austauschen kann.