Regarding the ViewModel

Question

Im struggling to understand the ViewModel part of the MVVM pattern. My current approach is to have a class, with no logic whatsoever (important), except that it implements INotifyPropertyChanged. The class is just a collection of properties, a struct if you like, describing an as small part of the data as possible. I consider this my Model.

Most of the WPF code I write are settings dialogs that configure said Model. The code-behind of the dialog exposes a property which returns an instance of the Model. In the XAML code I bind to subproperties of that property, thereby binding directly to the Model's properties. Which works quite well since it implements the INotifyPropertyChanged. I consider this settings dialog the View.

However, I havent really been able to figure out what in all this is the ViewModel. The articles Ive read suggests that the ViewModel should tie the View and the Model together, providing the logic the Model lacks but is still to complex to go directly into the View. Is this correct? Would, in my example, the code-behind of the settings dialog be considered the ViewModel?

I just feel a bit lost and would like my peers to debunk some of my assumptions. Am I completely off track here?

Answer 1

Since your model fits perfectly into your view, i.e., your view (settings dialog) can bind directly to the model's data structures, you are in the lucky situation of not needing a view model.

There are, however, many other cases where this is not the case: Imagine having a view that is a direct mapping of a database table, but you want a user interface which does not exactly match this abstraction.

Taking your example "settings dialog" example, let's say your model directly maps to a database table with setting_name, setting_value fields. In your view, however, you don't want the user to fill in some grid; rather, you want the user to fill in some "User Name", "Mail address", etc. fields. In that case, you could create a view model that exposes properties like UserName, MailAddress and internally maps them to your model.

Answer 2

What you consider your Model is in fact your ViewModel. The ViewModel is the class that supports the View. It often has an API that targets a particular technology (such as WPF or SilverLight).

Thus, the ViewModel can have ICommand properties, and properties that provide Colors or Brushes for databinding. It can also have properties that control whether specific controls are enabled or disabled, or visible at all.

All this is very View-oriented logic, and hence lives in the ViewModel.

In all but toy applications, you also need a proper Domain Model, but you don't want to pollute this model with all this View-oriented logic. It doesn't belong there - you might want to reuse the Domain Model to expose web services or a web site, and INotifyPropertyChanged, ICommand properties and whatnot does not belong there.

The Domain Model is your Model in the MVVM pattern. The ViewModel provides a bridge between the View and the Model.