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:

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(
    EnumExtensions.GetValues<NumberFormatCulture>().Select(TranslateEnum)))
.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; }
		set
		{
			name = value;
			RaisePropertyChanged("Name");
		}
	}

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

Links:
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
	}
}

Links:
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

Links:
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.

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

 

Command
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.

Links:
Wikipedia. Command pattern
MSDN. Commanding QuickStart

WPF and Silverlight Validation with IDataErrorInfo and INotifyDataErrorInfo

In this post I’ll describe how to use the IDataErrorInfo and INotifyDataErrorInfo interfaces to perform validation in WPF and Silverlight.
There are several kinds of validations and the preferrable approach in the MVVM pattern is using the IDataErrorInfo or INotifyDataErrorInfo interface.
But this approach doesn’t behave as expected: it performs validation immediately after the launch of the view, whereas it would be better if the validation started only after a user has changed values. Also I would like to reuse some commonly used rules.

So I’ve created the helper class which performs all the necessary work. This class is similar to the class from the FluentValidation library, but it has less code and more flexible to me.
Here is the example of such validation:

    public class PersonViewModel : IDataErrorInfo, INotifyPropertyChanged
    {
        private ModelValidator _validator = new ModelValidator();

        public PersonViewModel()
        {
            //Six validation rules
            this._validator.AddValidationFor(() => this.FirstName).NotEmpty()
				.Show("Enter a First Name");
            this._validator.AddValidationFor(() => this.LastName).NotEmpty()
				.Show("Enter a Last Name");

            this._validator.AddValidationFor(() => this.Age).NotEmpty()
				.Show("Enter an age");
            this._validator.AddValidationFor(() => this.Age).Between(0,99)
				.Show("The age must be between 0 and 99");

            this._validator.AddValidationFor(() => this.Email)
				.When(() => this.IsSubscribe).NotEmpty()
				.Show("Enter an email address");
            this._validator.AddValidationFor(() => this.Email)
				.When(() => this.IsSubscribe).EmailAddress()
				.Show("Enter a valid email address");
            //Validates on changes of properties
            this.PropertyChanged += (s, e) => this._validator.ValidateProperty(e.PropertyName);
        }

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

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

There is only 4 steps:
1. Create a variable of the ModelValidator type
2. Add necessary validation rules
3. Update validation every time when a property has been changed
4. Return cached errors inside the indexer property.

Actually it is not so obligatory to implement the 3rd step and update validation inside the PropertyChanged event handler. You can remove that line and call the ValidateAll method after a user clicks the Save button. But validation on changes is more preferrable solution.

I’ve added some predefined validation rules, if they aren’t enough, you can use the Must method with your own functions.
1. NotNull – the property value shouldn’t be null.
2. NotEmpty – if the property is of the string type, checks whether the string is null or consists of whitespaces. If of any other type – this rule is the same as NotNull.
3. Between – checks whether the property value is within a specific range. Works with strings as well as with numbers, so it’s not necessary to parse strings in view models.
4. EmailAddress – if the string value isn’t null, it should be a valid e-mail address.
5. Must – any user-defined validation function. For example: this._validator.AddValidationFor(() => this.LastName).Must(() => this.LastName.Length < 10).Show("Last name should not exceed 10 characters");

To implement this validation, you should copy 3 files with 2 classes to your project.
Here is the completed project where you can take all the necessary classes:
http://dl.dropbox.com/u/8047386/WordPress/WpfValidation.zip

Update
I’ve also added the validation for Silverlight both with IDataErrorInfo and INotifyDataErrorInfo:

The source code you can download here: SilverlightValidation.zip
Showcase: INotifyDataErrorInfoSampleTestPage.html