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