In MVVM, mit Entity Framework, was füllt das View-Modell?

Question

Ich schreibe eine WPF-Desktop-Anwendung. Ich versuche den MVVM-Datenfluss zu verstehen. Ich verwende Entity Framework als Datenzugriff und verwende einen Code-First-Ansatz, so dass ich meine POCO-Entity-Klassen habe, die jede SQL-Tabelle repräsentieren.

Mit dieser Konfiguration ist es mein Verständnis, dass mein Modell (M in MVVM) meine POCO-Entitätsklasse ist. Meine Ansichten (V in MVVM) sind meine WPF-Fenster.

Was bevölkert meine Ansicht Modelle? Mache ich einfach meine EF-Abfragen in meinen Ansichten und bearbeite die Ansichtsmodelle? Führen meine View-Modelle ihre eigene Abfrage durch (im Klassenkonstruktor vielleicht)?

Answer 1

In der Regel ist die Ansicht ein WPF-Fenster und der entsprechende Code dahinter. Das Ansichtsmodell ist eine einfache Klasse, die erstellt wurde, um die Datenschichtanforderungen für die bestimmte Ansicht zu erfüllen und die Verarbeitung durchzuführen. Es ist üblich, Befehle in der XAML-Ansicht der Steuerelemente zu verwenden, und jeder Befehl ist an eine Befehlsinstanz gebunden, die sich im Ansichtsmodell befindet. Das Ansichtsmodell kann durch Dependency-Injection erstellt werden, oder es kann in den Konstruktor im dahinter liegenden Views-Code übergeben werden, und es wird als Element/Eigenschaft im nachfolgenden Code gespeichert. Stellen Sie sicher, dass der Sichten-Datenkontext auf die Instanz des Ansichtsmodells festgelegt ist, um die Bindung an die Eigenschaften und Befehle im Ansichtsmodell zu ermöglichen.

Die Entity-Framework Plain Old CLR-Objekte sind Datenmodelle und die Ansicht sollte normalerweise nicht über diese wissen. Das Ansichtsmodell kann Eigenschaften der Modelltypen haben, an die die Ansicht beispielsweise für Items-Steuerelemente und ähnliches gebunden werden kann. So in der Ansicht:

<ItemsControl x:Name="CarItems" ItemsSource="{Binding Vm.CarsCollection}"></ItemsControl> 

Also, da die Datacontext-Ansicht eine Instanz des View-Modell-Typs ist, binden die Ansicht Kontrollen können direkt auf Objekte im Ansichtsmodell. Das Beispiel ist das Ansichtsmodell mit einer Sammlung von Autos und das Ansichtsmodell kann einen Dienst aufrufen, wenn es benötigt wird, um die Autosammlung zu füllen. Offensichtlich ist das ein Auto das Modell.

public MyViewModel() 
    { 
     Cars = TheCarsDataLayerService.GetCars(); 
    } 

    private IObservable<Car> _cars; 

    public IObservable<Car> Cars 
    { 
     get { return _cars; } 
     set 
     { 
      if(_cars == value) 
       return; 
      _cars = value; 
      RasisePropertyChanged("Cars"); 
     } 
    } 

Für die Autos Service int Beispiel Dies kann eine Datenschicht-Repository sein oder es könnte eine Instanz des Entity Framework DbContext sein.Das View-Modell kann also ein Feld vom DbContext-abgeleiteten Typ oder einen Service von solchem ​​haben und dies kann in den Konstruktor der View-Model-Klasse übergeben oder mit Dependency-Injection injiziert werden oder der Service ist eine statische Factory oder Singleton des View-Modells ruft nur auf, um seine Mitglieder mit den Daten zu füllen, die die Ansicht dem Benutzer anzeigen wird.

MVVM ist ein ziemlich einfaches Entwurfsmuster, das auf viele verschiedene Arten implementiert werden kann. Einige Entwickler werden das Muster zu neuen Höhen führen und streng Regeln folgen, in denen die Komponenten des Musters kommunizieren. Letztlich ist die Verwendung des Musters viel besser, als überhaupt kein Muster zu verwenden, unabhängig davon, wie es implementiert ist, da es den Code viel besser skalieren lässt und andere Entwickler den Code viel leichter verstehen und bestimmte Dinge erwarten können. Außerdem ermöglicht das MVVM-Muster WPF-Entwicklern den Komponententest. Wenn sie gut genug sind, können die Ansichtsmodelle getestet werden, und da in dem Sichtencode kein Code enthalten ist und die Ansicht nichts anderes tut, als Daten anzuzeigen, von denen sie nicht einmal weiß, ist das Testen des Ansichtsmodells gut genug.

Answer 2

Wenn Sie Ihre Domänenmodelle strikt als Ansichtsmodelle verwenden, werden Sie schließlich nicht sofort zu Problemen kommen. In der Regel besteht ein Domänenmodell aus Rohdaten, es kann Geschäftsvorgänge enthalten oder auch nicht, manche können dies beispielsweise in einer BusinessLayer-Manager-Klasse platzieren. Aber Sie VM ViewModel ist ausschließlich für die Ansicht, sollte nur in der Ansicht Projekt existieren. Wenn Sie Ihre Domain mit View-bezogenen Dropdowns usw. überlisten, ist das kein geeigneter Ort, um diese "View" -Datenquellen zu platzieren.

Um dies in Code-Begriffe zu setzen, kann Ihr Ansichtsmodell eine Eigenschaft enthalten, die auf eine Instanz des Domänenmodells verweist ODER Sie können jede Eigenschaft hinzufügen, die die Ansicht verfügbar macht. Durch die Trennung von ViewModel und Model (Domänenmodell) ermöglichen Sie der Ansicht, dass sie das, was sie benötigt, freilegen/verstecken sowie einige Eigenschaften konvertieren kann. Ein EntityFramework-Modell kann beispielsweise eine string -Eigenschaft enthalten, aber Ihre Ansicht möchte strikt numerische Darstellung auf einem Bildschirm, während ein anderer eine Bearbeitung als Zeichenfolgeneigenschaft zulässt, Punkt ist Ihr EF-Modell (Domänenmodell) muss sich nicht um diese Ansichtsprobleme kümmern.

Wo erstellen Sie die VM?

Die Aufgabe eines Controllers besteht darin, eine Anfrage zu interpretieren und das benötigte Ansichts- und Ansichtsmodell zu bestimmen. Es wäre also in der Steuerung, dass die VM unter Verwendung einer EF-Domänenmodellklasse (für eine Bearbeitungsanforderung als ein Beispiel) als die Quelle der VM erstellt wird.