MVVM - Difference between Model and ViewModel

Question

I've never used MVVM before, so I'm probably missing something obvious. When I create a new Panorama application, there's already a ViewModel folder containing ItemViewModel and MainViewModel.

I thought "MainViewModel.cs" is the file that organizes the panorama. However, within MainViewModel, it has this line:

    public MainViewModel()
    {
      this.Items = new ObservableCollection<ItemViewModel>();
    }

The ItemViewModel has no interaction with the panorama. These are the then instantiated like this:

this.Items.Add(new ItemViewModel() 
  { LineOne = "first line", LineTwo = "second line", LineThree = "third line" });

Why isn't ItemViewModel just a 'Model'? It implements INotifyPropertyChanged, but for what purpose? I would've thought that the ObservableCollection in MainViewModel would be enough to notify any changes, as demonstrated here

thanks

Answer 1

The ObservableCollection will notify when items are added or deleted from the list, but the INotifyPropertyChanged on the ItemViewModel is needed if you want notifications to happen when those properties change.

Answer 2

Difference is quite simple.

Model holds business logic.
View model contains presentation logic and is additionally shaped to fit views.

In Your case - view model implements INotifyPropertyChanged. That's pure presentation logic.

Model is not responsible for notifying one particular UI that something has changed, it's responsible for transferring invoices, calculating wages etc.

Sometimes (when model is simple) this abstraction is not necessary though.

---

Some wiki quotes:

Model: as in the classic MVC pattern, the model refers to either
(a) an object model that represents the real state content (an object-oriented approach), or
(b) the data access layer that represents that content (a data-centric approach).

ViewModel: the ViewModel is a “Model of the View” meaning it is an abstraction of the View that also serves in data binding between the View and the Model. It could be seen as a specialized aspect of what would be a Controller (in the MVC pattern) that acts as a data binder/converter that changes Model information into View information and passes commands from the View into the Model. The ViewModel exposes public properties, commands, and abstractions. The ViewModel has been likened to a conceptual state of the data as opposed to the real state of the data in the Model.

Answer 3

It's the same general concept behind all MV[x] architectures, albeit MVC, MVP or MVVM:

• You have the model on the one side, which is basically a software abstraction of your business domain. It does not know and does not care about any UI-related stuff (like e.g. in your case 'notifying the UI about changes'). It implements business logic and that's it.
• On the other side you have the UI, with specific needs both in technical terms (e.g. 'WPF wants to bind to an ObservableCollection') and also in terms of user presentation (think e.g. about different date orderings or different decimal signs in different languages).
• To cope with this and to be able to clearly separate these requirements in a clean architecture, you need the [x], in your case the ViewModel. It's the only layer within the software that knows both about the UI and the Model. Otherwise, there should be no connection whatsoever between the two.

In your simple example, this might look like overkill, but a normal business software will have dozens or even hundreds of such MV[x] triplets, and you would have no way to maintain a clean architecture without this.

To answer your question: What you have in your example is just a bit of wiring code to set up the described architecture.

HTH! Thomas