1. Introduction

Writing an application with good practices and proven architecture design is comparatively easy if we are going to write a new application. But most of the time we are working on existing applications, where it is not easy to make changes. If we ever get the chance to rewrite the existing application, we probably won't repeat the same mistakes that we or someone else made due to time constraints, technology limitation, scope creep etc. It would be better if we could refactor the existing codebase for betterment at the same time, with minimal or no risk effect.

Model-View-ViewModel (MVVM) is a proven design pattern used heavily in many WPF / Silverlight applications. But it might be possible that we already have a lot of code base that is not taking an advantage of it. This article focuses on implementing MVVM on existing applications rather than starting a new application. In this article we are going to see how we can take small steps towards MVVM. In the first part of this article, we are going to study the evaluation of MVVM and how we came to this point. The second part will examine the different steps to achieve MVVM. Although some steps have a major rework with the potential of high risk, there are still few things that have little or no effect on the project.

2. Evaluation of MVVM

Let's look at MVVM from a higher level and take a step-by-step approach to understanding it. Here our discussion is based on the complexity of the architecture from simple to complex, not from an historical order.

Probably the simplest design principle to separate the data from its presentation is Observer design pattern [1]. In Observer design pattern, we have two different classes for data (subject/model) or its presentation (observer/view). Subject classes contain the instance of all of the observers and send notification to all of observers when there is any change in the data. Here is a simple block diagram of observer design pattern.

Figure 1: Observer Desian Pattern

The next step is to introduce the middle layer in between the data and its presentation. The main purpose of this layer is to communicate between these two components. This is a main concept of Model View Controller (MVC) [2]. It is shown by this block diagram.

Figure 2: MVC

This approach has some advantages and disadvantages. The main disadvantage is that our view is not totally independent of our model. Model View Presenter (MVP) [3] handles exactly the same problem. In the MVP model there is no relation between View and Model.

Figure 3: MVP

MVVM is very similar to MVP pattern. Or it is some sort of specialized form of MVP pattern. In MVVM, Presentator is known as ViewModel. Model communicates with ViewModel with notification and ViewModel communicates with View with data binding and command binding as shown by this block diagram.

Figure 4: MVVM

Now let's take a more detailed look at MVVM. What is the biggest advantage of this? Its first advantage is that our presentation is totally unaware of our model. We don't write any user interface specific code in ViewModel and all the communication is based on data binding and command binding, which means we can easily write a unit tests for it. We can easily change any user interface or even change the data model easily. Here is a detail block diagram of MVVM.

Figure 5: MVVM

This diagram explains how we can take advantage of MVVM. The most important thing in this pattern is to properly design the ViewModel. WPF has very orthogonal design. It means we can customize or enhanced different parts of the library without affecting others. Most of the WPF reusability is based on composition rather than inheritance; therefore we can take maximum advantage of it, even at run time, because we can easily change the composition behavior at run time but not the inherited components. In this block diagram we see the major components of the WPF class library that we developed, enhanced or customized in most of the WPF application.

Figure 6: ViewModel

3. Switching to MVVM

We are going to start with a simple application, that is not written in WPF and gradually make step-by-step changes in it to introduce MVVM pattern. Our starting point is a loan amortization application written in VC++ and using WPF. The reason to pick that application is that by definition we can't use MVVM with VC++; XAML has very limited support in VC++ (The only support as of now is to load XAML at runtime and use it).

It is possible that we have some properties in our class that store data, but we usually have fields to store information. In our starting project, we have a class to store information about each payment. Here is our class.

public class PaymentInfo
{
	public int PaymentNo
	{ get; set; }

	public double Payment
	{ get; set; }

	public double Principle
	{ get; set; }

	public double Interest
	{ get; set; }

	public double Balance
	{ get; set; }
}

We have field variables to store information from the user interface and display it back to the user interface.

private double principle;
private double interestRate;
private int duration;
private double payment;

Here is a piece of code to get user input and store it in field variables

if (txtPrincipleAmount.Text.Length > 0)
{
	principle = Convert.ToDouble(txtPrincipleAmount.Text);
}
else
{
	MessageBox.Show("Please enter principle amount", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
	return;
}

if (txtInterestRate.Text.Length > 0)
{
	interestRate = Convert.ToDouble(txtInterestRate.Text);
	interestRate /= 100;
	interestRate /= 12;
}
else
{
	MessageBox.Show("Please enter interest", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
	return;
}

if (txtDuration.Text.Length > 0)
{
	duration = Convert.ToInt32(txtDuration.Text);
}
else
{
	MessageBox.Show("Please enter duration", "Error", MessageBoxButton.OK, MessageBoxImage.Error);
	return;
}

We have some utility methods to perform our calculations, which we call from our event handler.

// Calculate the remaining balance at particular payment
private double CalculateBalance(int month)
{
	double interestTerm = Math.Pow((1 + interestRate), month);
	double totalInterest = principle * interestTerm;
	double totalPaid = payment * (interestTerm - 1) / interestRate;
	return totalInterest - totalPaid;
}

// Calculate the Interest part of any particular payment
private double CalculateInterestPart(int month)
{
	double interestTerm = Math.Pow((1 + interestRate), (month - 1));
	double totalInterest = principle * interestTerm;
	double totalPaid = payment * (interestTerm - 1) / interestRate;
	return (totalInterest - totalPaid) * interestRate;
}

// Calculate the principle part of any particular payment
private double CalculatePrinciple(int month)
{
	return payment - CalculateInterestPart(month);

We have one method to calculate the amortization schedule for the complete loan period and add those values in DataGrid.

// Calculate the complete amortization schedule and fill the data grid control
private void CalculatePayment()
{
	int totalpayments = duration * 12;

	Title = "Amortization Schedule for " + 
		Convert.ToString(totalpayments) + " Payments";

	// calculate interest term
	double interestTerm = Math.Pow((1 + interestRate), totalpayments);

	// calculate payment
	payment = (principle * interestRate) / (1 - (1 / interestTerm));

	payments.Clear();

	for (int iIndex = 1; iIndex <= totalpayments; ++iIndex)
	{
		PaymentInfo paymentInfo = new PaymentInfo();
		paymentInfo.PaymentNo = iIndex;
		paymentInfo.Balance = CalculateBalance(iIndex);
		paymentInfo.Payment = payment;
		paymentInfo.Interest = CalculateInterestPart(iIndex);
		paymentInfo.Principle = CalculatePrinciple(iIndex);

		payments.Add(paymentInfo);
	}

	lstAmortization.ItemsSource = payments;
}

Note that the user interface code is heavily coupled inside the business logic, in this case calculating the loan amortization. There is no simple way to write test cases to check this calculation without involving the user interface.

The XAML of our project is very simple. Here is the complete XAML code of our program.

<Window x:Class="MVVM.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="400" Width="600">
    <Grid Background="Beige">
        <Grid.RowDefinitions>
            <RowDefinition Height="2*"/>
            <RowDefinition Height="2*"/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid Grid.Row="0">
            <Grid.ColumnDefinitions>
                <ColumnDefinition/>
                <ColumnDefinition/>
            </Grid.ColumnDefinitions>
            <Grid.RowDefinitions>
                <RowDefinition/>
                <RowDefinition/>
                <RowDefinition/>
                <RowDefinition/>
            </Grid.RowDefinitions>
            <TextBlock Grid.Column="0" Grid.ColumnSpan="2" Grid.Row="0" FontSize="18" FontWeight="Bold"
                       HorizontalAlignment="Center" VerticalAlignment="Center">Loan Amortization</TextBlock>
            <TextBlock Grid.Column="0" Grid.Row="1" VerticalAlignment="Center" Margin="5">Principle Amount</TextBlock>
            <TextBlock Grid.Column="0" Grid.Row="2" VerticalAlignment="Center" Margin="5">Interest Rate</TextBlock>
            <TextBlock Grid.Column="0" Grid.Row="3" VerticalAlignment="Center" Margin="5">Duration</TextBlock>
            <TextBox Grid.Column="1" Grid.Row="1" Margin="5" VerticalAlignment="Center" Name="txtPrincipleAmount"/>
            <TextBox Grid.Column="1" Grid.Row="2" Margin="5" VerticalAlignment="Center" Name="txtInterestRate"/>
            <TextBox Grid.Column="1" Grid.Row="3" Margin="5" VerticalAlignment="Center" Name="txtDuration"/>
        </Grid>
        <DataGrid Grid.Row="1" Name="lstAmortization" Margin="5">
        </DataGrid>       
        <Grid Grid.Row="2">
            <Grid.ColumnDefinitions>
                <ColumnDefinition/>
                <ColumnDefinition/>
            </Grid.ColumnDefinitions>
            <Button Grid.Column="0" Name="btnCalculate" Width="75" Height="45" Click="btnCalculate_Click">Calculate</Button>
            <Button Grid.Column="1" Name="btnExit" Width="75" Height="45" Click="btnExit_Click">Exit</Button>
        </Grid>
    </Grid>
</Window>

Also note that like other programming styles, here we have the name of every control.

3.1. Step 1: Use Properties

If code is using a field not properties, then convert those from field to properties. (This should have no or minimal effect on existing source code, because I chose property names very similar to (or the same) as fields. We simply change the uses the properties instead of fields in this step. Here is an updated version of our program.

public double Principle
{ get; set; }

public double InterestRate
{ get; set; }

public int Duration
{ get; set; }

public double Payment
{ get; set; }

There is no change in XAML of the program. If we use the same property name as the previously used field, then we don't have to change anything in the code either. In our example, I used the letter case for properties and camel case for fields, so we updated the source code accordingly and use letter case there.

3.2. Step 2: Implement INotifyPropertyChanged Interface / Dependency Property

My first step is to change the data model to make it WPF friendly. To do this I will either implement the INotifyPropertyChange interface or make them dependency property. If we already have properties, then this should have no effect at all for the rest of the project. The rest of the code should be the same and should work the same, but at least now you have your model ready.

In this example we are going to change our properties to dependency properties. In the coming steps we will see the example of the INotifyPropertyChanged interface too, to see both variants. Here is our updated code.

public static readonly DependencyProperty PrincipleProperty =
	DependencyProperty.Register("Principle", typeof(double), typeof(MainWindow));

public double Principle
{
	get { return (double)GetValue(PrincipleProperty); }
	set { SetValue(PrincipleProperty, value); }
}

public static readonly DependencyProperty InterestRateProperty =
	DependencyProperty.Register("InterestRate", typeof(double), typeof(MainWindow));

public double InterestRate
{
	get { return (double)GetValue(InterestRateProperty); }
	set { SetValue(InterestRateProperty, value); }
}

public static readonly DependencyProperty DurationProperty =
	DependencyProperty.Register("Duration", typeof(int), typeof(MainWindow));

public int Duration
{
	get { return (int)GetValue(DurationProperty); }
	set { SetValue(DurationProperty, value); }
}

public static readonly DependencyProperty PaymentProperty =
	DependencyProperty.Register("Payment", typeof(double), typeof(MainWindow));

public double Payment
{
	get { return (double)GetValue(PaymentProperty); }
	set { SetValue(PaymentProperty, value); }
}

There is no change in the XAML file.

3.3. Step 3: Use Data Binding

The next step is using Data Binding. This will reduce lots of thecodebase. Now it shouldn't have any code like this:

txtName.Text = firstName;

This is a major change in the code base. But at this step I focus only on data, not on behavior. My code still has event handlers and should work fine, but now I don't have to worry about updating the data into control or getting data from control to my variable. (No more control to variable interaction). Now we only check the invalid input directly from the properties (they automatically get values from the user interface). For validation purposes, we are going to introduce a new class inherited by ValidationRule class. Here is the code of our new class.

public class MyValidation : ValidationRule
{
	public override ValidationResult Validate(object value, System.Globalization.CultureInfo cultureInfo)
	{
		int number = Int32.Parse((string)value);

		if (number < 0)
		{
			return new ValidationResult(false, "Please enter values greater than zero.");
		}

		return new ValidationResult(true, null);
	}
}

Now we have to update our XAML and use the Data binding there. Here is an updated version of our XAML. In this version we also include our validation class to perform validation.

<TextBox Grid.Column="1" Grid.Row="1" Margin="5" VerticalAlignment="Center">
	<TextBox.Text>
		<Binding Path="Principle">
			<Binding.ValidationRules>
				<local:MyValidation/>
			</Binding.ValidationRules>
		</Binding>
	</TextBox.Text>
</TextBox>
<TextBox Grid.Column="1" Grid.Row="2" Margin="5" VerticalAlignment="Center">
	<TextBox.Text>
		<Binding Path="InterestRate">
			<Binding.ValidationRules>
				<local:MyValidation/>
			</Binding.ValidationRules>
		</Binding>
	</TextBox.Text>
</TextBox>
<TextBox Grid.Column="1" Grid.Row="3" Margin="5" VerticalAlignment="Center">
	<TextBox.Text>
		<Binding Path="Duration">
			<Binding.ValidationRules>
				<local:MyValidation/>
			</Binding.ValidationRules>
		</Binding>
	</TextBox.Text>
</TextBox>

We also define one style to display the error message when validation fails. Here is the code of our style.

<Style TargetType="{x:Type TextBox}">
	<Style.Triggers>
		<Trigger Property="Validation.HasError" Value="true">
			<Setter Property="ToolTip"
Value="{Binding RelativeSource={x:Static RelativeSource.Self},
				Path=(Validation.Errors)[0].ErrorContent}"/>
		</Trigger>
	</Style.Triggers>
</Style>

Also note that now we no longer need to specify the name of control; with the help of data binding we will automatically get the values in the correct property (dependency property in this example).

3.4. Step 4: Refactor Event Handler

This is an intermediate step. Now I already have all the data handling in the form of data binding with no control/variable code in it. I am going to iterate through all event handlers and whatever code is written there, move them into a method and call that method from the event handler. This is the updated version of our event handler now.

private void btnCalculate_Click(object sender, RoutedEventArgs e)
{
	CalculatePayment();
}

3.5. Step 5: Implement ICommand Interface

In the next step I am going to introduce the ICommand interface and implement it. There is no change for the existing codebase. Here is one example of it.

public class MyCommand : ICommand
{
	public Action Function
	{ get; set; }

	public MyCommand()
	{
	}

	public MyCommand(Action function)
	{
		Function = function;
	}

	public bool CanExecute(object parameter)
	{
		if (Function != null)
		{
			return true;
		}

		return false;
	}

	public void Execute(object parameter)
	{
		if (Function != null)
		{
			Function();
		}
	}

	public event EventHandler CanExecuteChanged
	{
		add { CommandManager.RequerySuggested += value; }
		remove { CommandManager.RequerySuggested -= value; }
	}
}

There is no change in XAML of our project.

3.6. Step 6: Add ICommand Properties

Now I am going to add properties in my class (which has event handler earlier). The type of that property is ICommand. This again should not have any effect on the rest of the code. The number of properties should be at least the same as the method I called inside the event handler and I chose a similar name.

public ICommand ExitCommand
{ get; set; }

public ICommand CalculateAmortizationCommand
{ get; set; }

There is no change in XAML of our project.

3.7. Step 7: Assign Methods to ICommand Type Properties

I have already created the method to calculate amortization (or do other work). Create object of MyCommand class and assign it to our ICommand properties in constructor.

ExitCommand = new MyCommand(Close);
CalculateAmortizationCommand = new MyCommand(CalculatePayment);

There is no change in XAML of our project.

3.8. Step 8: Use Command Binding

Remove the event handler from the code as well as from XAML and instead use the command binding. This is again a major change in the code (both code and XAML).

<Button Grid.Column="0" Name="btnCalculate" Width="75" Height="45" Command="{Binding CalculateAmortizationCommand}" >Calculate</Button>
<Button Grid.Column="1" Name="btnExit" Width="75" Height="45" Command="{Binding ExitCommand}" >Exit</Button>

Also note that now all of our business logic is in method, not in event handler, which means now we can somehow perform unit testing on those methods without any user interface involvement.

3.9. Step 9: Define ViewModel Class

Define a class to ViewModel and move all ICommand interface properties and methods assigned to it in this class. We introduced one event type property in our ViewModel class to handle the close event.

public event EventHandler RequestClose;

private void CloseWindow()
{
	EventHandler handler = this.RequestClose;

	if (handler != null)
	{
		handler(this, EventArgs.Empty);
	}
}

We set this event handler from our window (view) class. There are multiple ways to do this, but here we are doing this with unnamed delegate.

public partial class MainWindow : Window
{
	private MyViewModel vm = new MyViewModel();

	public MainWindow()
	{
		InitializeComponent();

		vm.RequestClose += delegate
		{
			Close();
		};

		DataContext = vm;
	}
}

Here is the complete code of our ViewModel class.

public class MyViewModel : DependencyObject
{
	public static DependencyProperty PrincipleProperty =
		DependencyProperty.Register("Principle", typeof(double), typeof(MainWindow));

	public double Principle
	{
		get { return (double)GetValue(PrincipleProperty); }
		set { SetValue(PrincipleProperty, value); }
	}

	public static DependencyProperty InterestRateProperty =
		DependencyProperty.Register("InterestRate", typeof(double), typeof(MainWindow));

	public double InterestRate
	{
		get { return (double)GetValue(InterestRateProperty); }
		set { SetValue(InterestRateProperty, value); }
	}

	public static DependencyProperty DurationProperty =
		DependencyProperty.Register("Duration", typeof(int), typeof(MainWindow));

	public int Duration
	{
		get { return (int)GetValue(DurationProperty); }
		set { SetValue(DurationProperty, value); }
	}

	public static DependencyProperty PaymentProperty =
		DependencyProperty.Register("Payment", typeof(double), typeof(MainWindow));

	public double Payment
	{
		get { return (double)GetValue(PaymentProperty); }
		set { SetValue(PaymentProperty, value); }
	}

	public event EventHandler RequestClose;

	public ObservableCollection Payments
	{ get; set; }

	public ICommand CalculateAmortizationCommand
	{ get; set; }

	public ICommand ExitCommand
	{ get; set; }

	public MyViewModel()
	{            
		CalculateAmortizationCommand = new MyCommand(CalculatePayment);
		ExitCommand = new MyCommand(CloseWindow);

		Payments = new ObservableCollection();
	}

	private void CloseWindow()
	{
		EventHandler handler = this.RequestClose;

		if (handler != null)
		{
			handler(this, EventArgs.Empty);
		}
	}

	// Calculate the complete amortization schedule and fill the list control
	private void CalculatePayment()
	{
		int totalpayments = Duration * 12;

		double monthlyInterest = CalculateMonthlyInterest(InterestRate);

		// calculate interest term
		double interestTerm = Math.Pow((1 + monthlyInterest), totalpayments);

		// calculate payment
		Payment = (Principle * monthlyInterest) / (1 - (1 / interestTerm));

		Payments.Clear();

		for (int iIndex = 1; iIndex <= totalpayments; ++iIndex)
		{
			PaymentInfo paymentInfo = new PaymentInfo();
			paymentInfo.PaymentNo = iIndex;
			paymentInfo.Balance = CalculateBalance(iIndex);
			paymentInfo.Payment = Payment;
			paymentInfo.Interest = CalculateInterestPart(iIndex);
			paymentInfo.Principle = CalculatePrinciple(iIndex);

			Payments.Add(paymentInfo);
		}

		//lstAmortization.ItemsSource = payments;
	}

	// Calculate the remaining balance at particular payment
	private double CalculateBalance(int month)
	{
		double monthlyInterest = CalculateMonthlyInterest(InterestRate);

		double interestTerm = Math.Pow((1 + monthlyInterest), month);
		double totalInterest = Principle * interestTerm;
		double totalPaid = Payment * (interestTerm - 1) / monthlyInterest;
		return totalInterest - totalPaid;
	}

	// Calculate the Interest part of any particular payment
	private double CalculateInterestPart(int month)
	{
		double monthlyInterest = CalculateMonthlyInterest(InterestRate);

		double interestTerm = Math.Pow((1 + monthlyInterest), (month - 1));
		double totalInterest = Principle * interestTerm;
		double totalPaid = Payment * (interestTerm - 1) / monthlyInterest;
		return (totalInterest - totalPaid) * monthlyInterest;
	}

	// Calculate the principle part of any particular payment
	private double CalculatePrinciple(int month)
	{
		return Payment - CalculateInterestPart(month);
	}

	// Calculate the monthly interest rate
	private double CalculateMonthlyInterest(double InterestRate)
	{
		double monthlyInterest = InterestRate;
		monthlyInterest /= 100;
		monthlyInterest /= 12;

		return monthlyInterest;
	}
}

Note this class doesn't have any user interface element so we can easily write test cases on it. In addition to this, if we want to change the presentation of this, such as WPF to Silverlight or a Console based application, we can do it very easily. This class contains all the business logic and now it is up to the user of this class how to present that information.

3.10. Step 10: Define ViewModelBase Class

Let's do one more step. We might want to do the same thing again and again, so why not create one base class to have minimum ViewModel functionality to reuse it in other ViewMode classes. One more reason to create a ViewModelBase class is to show how to implement the INotifyPropertyChanged interface. Here is the code of our base class.

public abstract class ViewModelBase : INotifyPropertyChanged
{
	public event EventHandler RequestClose;

	public ICommand ExitCommand
	{ get; set; }

	public void Close()
	{
		EventHandler handler = this.RequestClose;

		if (handler != null)
		{
			handler(this, EventArgs.Empty);
		}        
	}

	public void RaisePropertyChanged(string propertyName)
	{
		PropertyChangedEventHandler handler = PropertyChanged;

		if (handler != null)
		{
			handler(this, new PropertyChangedEventArgs(propertyName));
		}
	}

	public event PropertyChangedEventHandler PropertyChanged;
}

Also note that we made our ViewModelBase class abstract to avoid creating an object of this class. Here is part of our ViewModel class inherited by ViewModelBase.

public class MyViewModel : ViewModelBase
{
	public double principle;
	public double interestRate;
	public int duration;
	public double payment;

	public double Principle
	{
		get { return principle; }
		set
		{
			principle = value;
			RaisePropertyChanged("Principle");
		}
	}

	public double InterestRate
	{
		get { return interestRate; }
		set
		{
			interestRate = value;
			RaisePropertyChanged("InterestRate");
		}
	}

	public int Duration
	{
		get { return duration; }
		set
		{
			duration = value;
			RaisePropertyChanged("Duration");
		}
	}

	public double Payment
	{
		get { return payment; }
		set
		{
			payment = value;
			RaisePropertyChanged("Payment");
		}
	}

}

In this class we raise the property change event whenever there is a change in the property. There are lots of other things we can do to improve our code base, but this is just a first step in the right direction. We can easily include more steps in the following guidelines, but after following these steps we will have a reasonably good design of our program towards MVVM.

Here is the output of this program.

[MVVM_07.gif]
Figure 7: Loan Amortization Output

4. References

1. Design Pattern, Elements of Reusable Object Oriented Software
Erich Gamm, Richard Helm, Ralph Johnson, John Vlissides

2. A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80
Glenn E. Krasner, Stephen T. Pope
Journal of Object Oriented Programming, August/September 1988
http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf

3, GUI Architectures
Martin Fowler
http://www.martinfowler.com/eaaDev/uiArchs.html

4. Loan Amortization Application in WPF using C++
Zeeshan Amjad
http://www.codeproject.com/KB/WPF/LoanAmortizationWPF.aspx
http://www.codeguru.com/cpp/cpp/cpp_managed/general/print.php/c16355/