MVVM Part 1: Overview

There have already been quite a few articles, HOW-TOs and tutorials to the Model-View-ViewModel (MVVM) architecture.

One of the best is WPF Apps With The Model-View-ViewModel in my opinion.

However, I have different or advanced solutions for some problems. So I’ll start a series with an unknown number of parts about this topic.

Still, I explicitly recommend reading the others, too. Only this will help you to find your interpretation of MMVM.

What is MVVM?

MVVM is a pattern that helps to separate the behavior of an User Interface from its design.

Why doing so?

There are several reasons for that:

  • Separation: UI and logic are separated for changing them without affecting the other one
  • Testing: Plain UIs can not be tested easily. ViewModels can.
  • Support of different views: You want to create multiple UIs for an application? That’s much easier
  • Ease of the use of WPF Controls: Ever tried to fill a Treeview in WPF without MVVM? It’s quite uncomfortable.
  • Taking advantage of WPF-Features like Data Templates, Data Binding and dynamic Control creation

The three players

The Model


In short, the Model is the “real application”. It represents all the business logic.

Do not see the Model as something passive or as something that contains no logic!

Where are its limits?

The Model shouldn’t contain any logic to directly interact with the user. This shouldn’t be any new information.

This includes displaying of Windows / Forms / MessageBoxes but also formatting data. That’s none of their business!


A little “checklist” for a good Model (of course, there may be exceptions here); arbitrary order:

  • Did I use no class contained in System.Windows (and inferior namespaces)? Thus, I need no reference to PresentationFramework.dll, System.Windows.Forms, PresentationCore, …?
  • Is it neither laid out for Windows Forms, nor WPF? Could I use everything in a Console Application theoretically?
  • Am I using content that needs to be translated? It’s only OK for messages that won’t displayed to the user. (Exceptions – if you prefer using localized ones – and Logfiles can be exceptions)
  • Is there no need of additional logic concerning working with my Model-classes? That means: Every kind of manipulation the application itself does to its data (e.g. functions like “Load the latest stocks from our homepage” or “Do an automatic cleanup and delete all Customers that made no order during the last year”) should be implemented here.
  • Does my Model perform validation?
  • Did I implement code to fetch objects from my data store and save it there? Is this procedure abstracted by my Model? Did I also abstract the specific queries so the user of my classes doesn’t need to know about the structure of my database?
  • Did I use events when requiring feedback from the user?

The ViewModel

Well, what is the ViewModel then?

According to my definition it is a layer which is databound to the view and prepares the model in order to be displayed by it. It does so by providing a kind of proxy classes. Thereby it simplifies complicated situations by changing the structure of the model.

What does it do?

As already said in the definition: Its main task is simplifying and restructuring data in a form that can’t be visualized directly by the view. Everything is supplied in a bindable way by implementing INotifyPropertyChanged.

Every action you can perform (this also includes object creation) is exposed as a command.

There are three “base” types of patterns: Selecting one or more items, Changing a property, Invoking a method.

Where are its limits?

The ViewModel should not know about the concrete view. Only the structure of a view is considered when creating it. By saying “structure” I neither mean the layout nor the real “looking”. “Structure” describes what a user can actually do – something like “There is a possibility to change the name of a person.” or “Items can be deleted, added, and reordered here”.

In my opinion, formatting (of primitive values – e.g. setting the number of decimal points or combining two or more properties to a new one) is also not a part of the ViewModel.

One important thing, a ViewModel should never do: Do not use classes from “System.Windows”. That means: No MessageBox.Show, no creation of Windows, …

  • Is the ViewModel “easy” to use?
  • Does it track property changes and report them via INotifyPropertyChanged?
  • Do all properties either return another ViewModel, a primitive data type or a collection of one of these?
  • Does it not contain any String.Concats, String.Formats, … in order to combine two or more properties to a new one?
  • Are there commands for every action you can do with the ViewModel?
  • Is it independent of the current UI?
  • Did I use no classes declared in “PresentationFramework.dll” (which includes all controls)?
  • Is every action exposed as a command?

The View


The view is the “real UI” or simply “that thing you can really see”. For each ViewModel there is exactly one UserControl representing it.

This UserControl is assembled out of existing controls (of course there can be user generated controls – however, these controls should be independent). It has no code-behind and only consist of XAML-Code. Data Templates, Data Binding, Styles and Resources are used to a great extent.

All formatting, arrangement and visualizing of data is done here.

Where are its limits?

Although the View displays everything, it’s designed more passive than active. It only invokes commands, and changes databound properties. It will never change something by code.

Therefore, it contains no program logic.

  • Does the View only use the ViewModel (and not the Model) classes?
  • Is the View free of logic that affects more than the UI itself?
  • Is there exactly one UserControl per each ViewModel class?
DotNetKicks Image