Klasyfikacja i nazewnictwo dla Modelu i ViewModel w MVVM

Question

Jestem zdezorientowany tym, czym powinien być model lub model widoku i jak powinny być one nazwane.

Dla uproszczenia zostawię INotifyPropertyChange z tego.

Poniższa klasa jest wyraźnie model:

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

Co najczęściej zobaczyć na stronie internetowej jest to, że model widok byłby zdefiniowany następująco:

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

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

Dlaczego nie jest powyżej model Countries, np. CountriesModel, na przykład? Dlaczego jest uważany za model widoku?

Czy to technicznie rzecz biorąc? Czy powinniśmy mieć kolejną klasę dla modelu widoku?

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; 
    } 
} 

Czy powyższe ma sens? Po prostu nie rozumiem, dlaczego wydaje się być standardem i dlaczego miałbyś nazywać się CountriesViewModel, gdy dla mnie powinien to być CountriesModel i należy utworzyć CountryViewModel uzyskując dostęp do danych z CountriesModel.

Ponadto, jeśli trzymać się tego, co znajduje się w internecie, to znaczy CountryModel i CountryViewModel który zawiera zbiór CountryModel zaobserwowania, to w jaki sposób radzić sobie z krajów zawierających każdą listę miast? Będę miał CityModel jako POCO, a następnie dla listy miast, utworzę CityViewModel o widocznej kolekcji CityModel.

Ale co wtedy? Czy mam ustawić CityViewModel część mojego CountryModel? To wcale nie wydaje się w porządku! Być może tak jest i ktoś może to wyjaśnić. To jest, gdzie jestem zdezorientowany jeszcze bardziej, ponieważ utworzyłem CountryModel o właściwościach Name, Location i właściwości typu List<CityModel>, ale jak mam to poprawnie przedstawić w MVVM?

Jak zdefiniować to poprawnie? Zwłaszcza część, w której masz listę obiektów i każdy z tych obiektów zawiera inną listę. Który model, model widoku i jak mam obsłużyć listę wewnątrz mojego modelu?

Answer 1

Zazwyczaj ludzie tworzą model widoku dla każdego widoku, który mają w swoim systemie. Celem modelu widoku jest ułatwienie danych widoku. Modele widoku to zazwyczaj spłaszczona wersja odpowiedników modelu domeny, ale może to wydawać się zagmatwane, gdy masz płaskie modele domen, które w rzeczywistości są tylko obiektami transferu danych (DTO). Nie bój się mieć modeli widoków, które bardzo przypominają model domeny; są to różne abstrakcje danych przeznaczonych do życia i pracy w różnych obszarach/warstwach aplikacji.

Jeśli chodzi o twoje pytania/przykłady, jeśli miałeś widok w swoim zgłoszeniu, który reprezentowałby kraje i miasta w sposób hierarchiczny, to tak, byłoby całkowicie dopuszczalne, aby mieć CountryViewModel, który składał się z CityViewModel, wraz z każdym innym zobacz modele, które pomogły w utworzeniu danych dla tego widoku. Możliwe jest również użycie dziedziczenia w modelach widokowych, aby można było uzyskać klasę modelu widoku podstawowego, w której przechowywano informacje o błędach w przypadku jakichkolwiek błędów, takich jak problemy z odzyskiwaniem danych, problemy z mapowaniem danych lub problemy z weryfikacją danych.

Ponieważ będziesz zazwyczaj chcą mieć widoku modelu za oglądanie w swojej aplikacji, wiele razy skończyć z zestawu widoków modeli pasujących operacje CRUD dla Twojego modelu domeny obiektu. Załóżmy, że masz model Account domeny, wtedy prawdopodobnie masz CreateAccountViewModel, DisplayAccountViewModel, DeleteAccountViewModel i UpdateAccountViewModel.

Wiele osób obawia się duplikacji w swoim kodzie i uważa, że ​​błędem jest posiadanie modelu domeny i modelu widoku, który jest prawie identyczny pod względem struktury i typów danych, ale pamiętaj, że służą one bardzo różnym celom; istnieją modele dziedzinowe, które ułatwiają dane dla przestrzeni problemowej, w której pracujesz, podczas gdy modele widoku istnieją w celu ułatwienia danych do wyświetlania informacji użytkownikowi w widoku.

Nie można również nie zauważyć, że klasa modelu danych w warstwie dostępu do danych różni się od modelu domeny, ale odzwierciedla strukturę danych pobieranych z tabeli bazy danych. W ten sposób można użyć mikro-ORM, takiego jak Dapper. Zamiast pisać odwzorowanie logiki ADO.NET DataReader, należy utworzyć klasę modelu danych, który pasuje do nazwy kolumn w zapytaniu użyć, aby pobrać dane z bazy danych, a następnie użyć tej klasy jako obiektu do „zrzucić” danych do. Stamtąd można utworzyć logikę mapowania, aby zbudować klasę modelu domeny, która zostanie przekazana z powrotem do warstw aplikacji.