Erläuterung und Namenskonvention für Modell und ViewModel in MVVM

Question

Ich bin verwirrt in was ein Modell oder ein Ansichtsmodell sein sollte und wie diese benannt werden sollten.

Der Einfachheit halber lasse ich die INotifyPropertyChange raus.

Die folgende Klasse ist eindeutig ein Modell:

class CountryModel 
{ 
    public string Name { get; set; } 
    public string Location { get; set; } 
} 

Was Sie meist auf dem Netz zu sehen ist, dass ein Ansichtsmodell definiert werden würde, wie folgt:

class CountryViewModel 
{ 
    public CountryViewModel 
    { 
     // initialize data (not ideal place, I know, but keeping it simple!) 
    } 

    public ObservableCollection<CountryModel> Countries 
    { 
     private get; 
     set; 
    } 
} 

Warum nicht die oben ist ein Modell von Countries, dh CountriesModel, zum Beispiel? Warum wird es als Ansichtsmodell betrachtet?

Sollte das technisch der Fall sein? Sollten wir eine andere Klasse für das View-Modell haben?

class CountryViewModel 
{ 
    private ObservableCollection<CountryModel> _countries = new ....; 

    public CountryViewModel 
    { 

    } 

    public ObservableCollection<CountryModel> Countries 
    { 
     private get { return _countries ?? _countries = LoadCountries(); } 
     set { _countries = value; } 
    } 

    private ObservableCollection<CountryModel> LoadCountries() 
    { 
     ObservableCollection<CountryModel> countries = new ...; 
     foreach (CountryModel country in CountriesModel) 
     { 
      countries.add(country); 
     } 
     return countries; 
    } 
} 

Ist das oben genannte sinnvoll? Ich verstehe nur nicht, warum es ein Standard zu sein scheint und warum Sie CountriesViewModel anrufen würden, wenn es CountriesModelCountriesModel sein sollte und ein CountryViewModel sollte erstellt werden, Zugriff auf die Daten von der CountriesModel.

Auch, wenn Sie zu halten, was auf dem Netz, das heißt CountryModel und CountryViewModel, die eine beobachtbare Sammlung von CountryModel enthält, dann, wie würden Sie mit Ländern beschäftigen sich eine Liste der Städte enthalten? Ich hätte eine CityModel als POCO und dann für die Liste der Städte, würde ich eine CityViewModel mit einer beobachtbaren Sammlung von CityModel erstellen.

Aber was dann? Soll ich den CityViewModel Teil meiner CountryModel machen? Das scheint gar nicht richtig zu sein! Vielleicht ist es und jemand könnte das klären. Dies ist, wo ich noch mehr verwirrt, da ich eine CountryModel mit den Eigenschaften Name, Location und eine Eigenschaft des Typs List<CityModel> erstellt hätte, aber wie stelle ich das korrekt in MVVM?

Wie definiere ich das richtig? Insbesondere der Teil, in dem Sie eine Liste von Objekten und jedes dieser Objekte haben, enthält eine andere Liste. Welches ist ein Modell, ein Ansichtsmodell und wie handhabe ich die Liste in meinem Modell?

Answer 1

In der Regel erstellen Personen ein Ansichtsmodell für jede Ansicht, die sie in ihrem System haben. Der Zweck des Ansichtsmodells besteht darin, die Daten der Ansicht zu erleichtern. Ansichtsmodelle sind normalerweise eine flachere Version ihrer Gegenstücke im Domänenmodell. Dies kann jedoch verwirrend sein, wenn Sie flache Domänenmodelle haben, bei denen es sich lediglich um Datenübertragungsobjekte (DTOs) handelt. Haben Sie keine Angst, Ansichtsmodelle zu haben, die einem Domänenmodell sehr ähnlich sind; Sie sind unterschiedliche Abstraktionen der Daten, die in verschiedenen Bereichen/Schichten Ihrer Anwendung leben und arbeiten sollen.

Wie für Ihre Fragen/Beispiele, wenn Sie einen Blick in Ihrer Anwendung haben, die dann in einer hierarchischen Art Länder und Städte vertrat ja wäre es durchaus akzeptabel sein, ein CountryViewModel zu haben, die von einem CityViewModel, zusammen mit allen anderen zusammengesetzt waren, Modelle anzeigen, die dazu beigetragen haben, die Daten für diese bestimmte Ansicht zu bilden. Es ist auch möglich, die Vererbung in Ansichtsmodellen zu verwenden, sodass Sie eine Basissichtmodellklasse mit Fehlerinformationen für alles haben können, was schief gegangen ist, z. B. Probleme beim Abrufen der Daten, Probleme beim Zuordnen der Daten oder Probleme beim Validieren der Daten.

Da Sie im Allgemeinen ein Ansichtsmodell pro Ansicht in Ihrer Anwendung haben möchten, erhalten Sie häufig eine Reihe von Ansichtsmodellen, die den CRUD-Operationen für Ihr Domänenmodellobjekt entsprechen. Angenommen, Sie haben ein Account Domänenmodell, dann hätten Sie wahrscheinlich eine CreateAccountViewModel, DisplayAccountViewModel, DeleteAccountViewModel und UpdateAccountViewModel.

Viele Menschen machen sich Gedanken über die Duplizierung ihres Codes und denken, dass es falsch ist, ein Domänenmodell und ein Modell zu haben, die in Struktur und Datentypen fast identisch sind, aber bedenken Sie, dass sie sehr unterschiedlichen Zwecken dienen; Domänenmodelle existieren, um die Daten für den Problembereich zu vereinfachen, in dem Sie arbeiten, während Ansichtsmodelle vorhanden sind, um die Daten zum Anzeigen von Informationen für den Benutzer in einer Ansicht zu vereinfachen.

Es ist auch nicht ungewöhnlich, eine Datenmodellklasse in einer Datenzugriffsebene zu verwenden, die sich vom Domänenmodell unterscheidet, aber die Struktur der Daten widerspiegelt, die aus einer Datenbanktabelle abgerufen werden. So können Sie ein Mikro-ORM wie Dapper verwenden. Anstatt die ADO.NET DataReader Zuordnungslogik zu schreiben, erstellen Sie eine Datenmodellklasse, die den Spaltennamen in der Abfrage entspricht, die Sie zum Abrufen der Daten aus der Datenbank verwenden, und verwenden diese Klasse dann als Objekt zum "Ablegen" der Daten. Von dort aus können Sie über eine Zuordnungslogik eine Domänenmodellklasse erstellen, die in den Schichten Ihrer Anwendung zurückgegeben wird.