Clarification and naming convention for model and ViewModel in MVVM

Question

I am confused by what should be a model or a model of representation and what they should be called.

For simplicity, I will leave INotifyPropertyChange out of it.

The following class is explicitly a model:

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

Basically, you see on the Internet that the presentation model will be defined as follows:

 class CountryViewModel { public CountryViewModel { // initialize data (not ideal place, I know, but keeping it simple!) } public ObservableCollection<CountryModel> Countries { private get; set; } } 

Why, for example, there is no Countries model, i.e. CountriesModel ? Why is this considered a presentation model?

Should it be technically? If we have another class for the view model, then?

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

Is this the foregoing? I just don’t understand why this looks like a standard, and why you would call CountriesViewModel , when I should have CountriesModel , and CountryViewModel should be created to access data from CountriesModel .

Also, if you stick to what's on the Internet, i.e. CountryModel and CountryViewModel , which contains an observable collection of CountryModel , how will you deal with countries containing each list of cities? I would have CityModel as POCO, and then for a list of cities, I would create a CityViewModel that has an observable collection of CityModel .

But then what? Am I supposed to make CityViewModel part of my CountryModel ? This does not seem right! Maybe this is so, and someone can clarify this. Here I am even more confused since I created a CountryModel with Name , Location properties and a property of type List<CityModel> , but how to correctly represent it in MVVM?

How to determine this correctly? Especially in the part where you have a list of objects, and each of these objects contains a different list. What model, view model, and how do I process the list inside my model?

Answer 1

As a rule, people create a representation model for each species that they have in their system. The purpose of the presentation model is to facilitate the presentation of data. View models are usually a flattened version of their peers in a domain model, but this may seem confusing when you have flat domain models that are actually data transfer (DTO) objects. Don't be afraid to have view models that are very similar to a domain model; they are different data abstractions intended for life and work in different areas / layers of your application.

As for your questions / examples, if you had a view in your application that represented countries and cities by hierarchical nature, then yes, it would be perfectly acceptable to have a CountryViewModel , which consisted of a CityViewModel , along with any other view models that helped compose data for this particular species. It is also possible to use inheritance models in the view so that you can have a base view model class that contains error information for something that went wrong, for example, problems with receiving data, problems with displaying data, or problems with validating data.

Since you usually want to have a view model for the view in your application, you get many times a set of view models that correspond to the CRUD operations for the domain model object. For example, let's say you have an Account domain model, then you will probably have CreateAccountViewModel , DisplayAccountViewModel , DeleteAccountViewModel and UpdateAccountViewModel .

Many people are concerned about duplication in their code and believe that it is wrong to have a domain model and a review model that are almost identical in structure and data types, but remember that they serve completely different purposes; there are domain models to facilitate data for the problem space in which you are working, while viewing models exist to facilitate data for displaying information to a user in a view.

There is also no unheard of presence of a data model class at the data access level, which differs from the domain model, but reflects the structure of the data retrieved from the database table. Here is how you can use micro-ORM like Dapper . Instead of writing the ADO.NET DataReader display logic, you create a data model class that matches the column names in the query, which is used to retrieve data from the database, and then use this class as an object to dump data into. From there, you can have matching logic to create a domain model class that will be passed back down through your application layers.