The necessity of a ViewModel class for each Model class

It is well known that you need a ViewModel if you want to add property change notification or validation to a Model. But what if the Model and ViewModel classes don’t differ at all? Should you create a ViewModel class if it has the same set of properties that the Model class has? The answer is yes, absolutely. The brief reasons are separation of layers and loose coupling. But I know that these abstract terms don’t sound very convincing so I’ll describe my point of view more particularly in this post.

As an example I’ll use this data source class (which can be either a web service, or a database, or a file, whatever) and this model:

public interface IModelSource
    SettingsModel GetSettings();

public class SettingsModel
    public string DefaultPage { get; set; }

    public string DownloadsFolder { get; set; }

    public bool AutoStart { get; set; }

So we should choose which approach to use.
Just to bind the model as it is:

SettingsModel model = source.GetSettings();
this.DataContext = model;

Or to use the extra ViewModel layer and convert the model before binding:

SettingsModel model = source.GetSettings();
SettingsViewModel viewModel = ConvertModelToViewModel(model);
this.DataContext = viewModel;

Let’s examine some cases and look at the differences between the approaches above.


1. Remove a property from the model class.
It happens quite often during development, this type of changes can be performed on the service side or in the database. So if to remove the AutoStart property, what will happens then?

The model-only approach
You will not be aware of the error and will not notice it until you run your application, navigate to the corresponding view and look at the Output window. There among messy messages you will see the notification about the binding error:
Runtime binding error
Also you should run your application in the Debug mode. If you start it by using the Ctrl+F5 combination, you will never find the error.

The viewmodel approach
You will be notified about the error almost immediately before you run the application. And you know: the earlier the bug is found – the easier to fix it.


2. Add a property of a complicated data type to the model class.
For example, this property of the Enum type:

NumberFormatCulture NumberFormat { get; set; }

The model-only approach
It isn’t clear how to bind this enum to the ComboBox control (I think, you will not display such programming language related values as “EnglishUS” to end users, won’t you?), so you’ll search it on Google or StackOverflow and eventually you’ll choose either a hacky solution (which will work only for the particular case) or you’ll agree to use the ViewModel (and admit wasting the time).

The viewmodel approach
Just add a few lines to the mapping configuration which can be easily bound to the ComboBox:

//Mapper.CreateMap ... 
.ForMember(vm => vm.NumberFormats, option => option.UseValue(
.ForMember(vm => vm.SelectedNumberFormat, option => option.MapFrom(
    m => TranslateEnum(m.NumberFormat)))


3. Change the structure of the model class.
For example, if to change some property of the string type to the property of another model type:

public PageModel DefaultPage { get; set; }

public class PageModel
    public string Url { get; set; }

The model-only approach
Again, you will not notice the error until you run the application and look at the Ouput Window (see p.1). Then you should run over all the xaml-markup in the view and correct bindings. And of course launch the application once again to assure that everything is fine after the changes.

The viewmodel approach
Just fix one line of the code in the mapping configuration:

//Mapper.CreateMap ... 
.ForMember(vm => vm.DefaultPage, option => option.MapFrom(m => m.DefaultPage.Url))

I must say that in this case the mapper doesn’t perform compile-time checking, but you can configure it so that it throws an exception if you try to map from the object type to the string type. And exceptions are any easier to notice and understand than debug messages in the Output window.


4. Project structure and maintenability
It isn’t a big advantage of the viewmodel approach in comparison with the above described points, but anyway, it is much better to have a good project structure when each view has a corresponding view model with the same class name prefix. You will not search which model class is bound to, for example, the SettingsView class (which model class: UserSettingsModel, ServiceSettingsModel? I don’t remember so I’ll take some time to find it out). You’ll just open the folder with view models and immediately see the corresponding SettingsViewModel class.


The most popular exuse not to create the extra layer is because it allegedly takes much time. But if to calculate the exact amount, the statement will be far from the truth.
– Add the AutoMapper library by using the NuGet package manager – 20 second (this task is performed only once)
– Create a new ViewModel class and just copypaste all of the properties of the model – 30 seconds
– Configure the mapping by using code-snippets – 5 seconds per property.

So it’ll take something about 1-2 minutes to create a ViewModel and I can’t say that it is a “huge amount of time”. And this amount is nothing in comparison with the time wasted on the above described points if to use the wrong approach. Don’t afraid to spend few minutes now, it will save many hours in the future.

WPF and Silverlight design patterns

In this post I’ll describe the design patterns which are used in large and complex applications in order to simplify their development and maintenance.

Model View ViewModel
Separates Model and View by introducing the intermediate layer which is called ViewModel. It is a some kind of a “super converter” which adds additional properties and behavior to the model. Also commonly used as a replacement of code-behind.
The most common features of ViewModel:

  • Property changes notification with the INotifyPropertyChanged interface
  • Validation with the IDataErrorInfo or INotifyDateErrorInfo interfaces
  • Event handling of View events
  • Invocation of WCF services
  • Converting of model properties from one data type to another

Example of Model and ViewModel:

public class UserModel
	public string Name { get; set; }

public class UserViewModel : IDataErrorInfo, INotifyPropertyChanged
	private string name;

	public string Name
		get { return name; }
			name = value;

	public ICommand ChangeNameCommand { get; set; }

	public string Error
		get { throw new NotImplementedException(); }

	public string this[string columnName]
		get { return this._validator.GetErrors(columnName).FirstOrDefault(); }

	public event PropertyChangedEventHandler PropertyChanged;

	private void RaisePropertyChanged(string propertyName)
		if (this.PropertyChanged != null)
			this.PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

Wikipedia. Model View ViewModel
Developer’s Guide to Microsoft Prism. Implementing the MVVM Pattern
Never In Doubt: MVVM Backlash


Dependency Injection
The purpose of this pattern is to get rid of using of external classes and to use interfaces instead.
This pattern adds the following benefits:

  • Allows to write unit tests because interfaces can be replaced by “fake” classes
  • Allows to change one interface implementation by another without affecting or changing existing objects

For example, this class:

public class MyViewModel
	public MyViewModel()
		this.SomeProperty = Resources.String1; // the static class call

	public void Refresh()
		var model = new MyWcfServiceClient().GetModelById(this.Id); // the service creation

        // initialize the corresponding properties of the view model

should be rewritten so:

public class MyViewModel
	public MyViewModel(IResourceManager resourceManager, IServiceClient serviceClient)
		this._resourceManager = resourceManager;
		this._serviceClient =  serviceClient;

		this.SomeProperty = this._resourceManager.String1;

	public void Refresh()
		var model = this._serviceClient.GetModelById(this.Id);

        // initialize the corresponding properties of the view model

Wikipedia. Dependency injection
MSDN Magazine. Design Patterns: Dependency Injection


Modular Application
This concept is based on the logical division of application components and if you use several projects with different functionality, you already use a some kind of modules. For example, if your solution has projects like Application.Mail, Application.Calendar, Application.Tasks – it has 3 modules as well.

Besides the above mentioned logical division, the Prism framework adds the following features:

  • Allows to add modules after the application is released (some kind of plug-ins)
  • Allows to defer module loading and load some of them on demand

Developer’s Guide to Microsoft Prism. Modular Application Development


Event Aggregator
This pattern is known as Messenger in the MVVM Light Toolkit. Implements the “publish-subscribe” model. For example, if one view model should call a method of another view model, it can be done by using two ways:
1. Bad practice: The first view model gets the second view model as the constructor parameter and then calls the necessary methods directly by using the code like this._otherModel.OnUserUpdated(this).
2. The preferred approach: The second view model publishes an event, the first one subscribes to it and handles appropriately.

Martin Fowler. Event Aggregator
Developer’s Guide to Microsoft Prism. Communicating Between Loosely Coupled Components


Allows to get rid of the code-behind and handle button clicks inside a view model. Also it is useful when the same action is invoked from the application menu, context menu, toolbar and buttons, so you don’t need to write separate event handlers and you can use just a single command everywhere.
Besides the method invocation, commands in WPF affects the IsEnabled property of buttons and menu items as well: if a command can’t be executed, all the invoke buttons will be disabled.

Wikipedia. Command pattern
MSDN. Commanding QuickStart

Windows 8 Items controls

In addition to the single-item controls, Windows 8 as well as WPF provides controls for multiple child items by using classes derived from the ItemsControl class.

Common items controls in Windows 8 are:
ListBox – A list of selectable items (the same as the WPF counterpart).
ComboBox – A selection control that combines a non-editable text box and a drop-down containing a list box (the same as the WPF counterpart).
FlipView – Displays one item at a time and allows to traverse its items by using either pop-up arrows or the “flip” gesture.
ListView – Displays a list of items, similar to the ListBox control, but with a difference that it can be used with the JumpViewer control (I’ll try to describe it some time later).
GridView – A specialized ListView which displays items in a form of grid. The same can be achieved by using the ListView control and the wrap panel inside its ItemsPanelTemplate.

Here are sample screenshots of above described controls:

Windows 8 ItemsControls: Listbox, ComboBox, FlipView, ListView

Windows 8 ItemsControl: GridView

The following items controls are not available in Windows 8:

I hope some of them will be available after the final release in the form of Toolkit, like it was with Silverlight.

Windows 8 controls

Today I’ll compare built-in controls in Windows 8 and their counterparts in WPF and Silverlight. I’ll describe all the control classes except the ItemsControl classes and panels.

You can see the most often used controls of Windows 8 in the following illustration:

The following controls are supported by both WPF/Silverlight and Windows 8 technologies:

The following controls are not available in Windows 8:

The following controls exists only in Windows 8:
ProgressRing – displays an indeterminate circular animation, switched by the property IsActive;
RichTextBlock – the read-only version of the RichTextBox;
ToggleSwitch – looks the same as the CheckBox control with the custom template.

Also the following controls are different at some point in Windows 8:
TextBlock – can contain the same tags as the RichTextBlock has such as Italic, Underline, LineBreak, etc;
TextBox – has the clear button on the right which removes all the text;
PasswordBox – has the reveal button on the right which displays the password as a decoded text.

That’s all the differences which I’ve noticed so far, next time I’ll describe the ItemsControl classes.