Why Use the MVVM Pattern with Silverlight Applications?

The probability of hearing or reading about the title question of this article if you are either a Silverlight or WPF developer is substantial. However, there are significant problems when searching for a proper answer to this question.

To begin with, there are numerous and varied ways in implementing methodologies like MVVM, most of which are used based on personal preference. To a novice trying to educate themselves, this leads to disparity in information. Complicating this factor is that many of the articles or videos that attempt to describe the MVVM pattern also include components of other architectural patterns. This adds unnecessary complexity to understanding the MVVM pattern because of the inconsistencies in the pattern being described. In this article, I will elucidate only the MVVM pattern - nothing more, nothing less.

First of all, let me answer the title question succinctly. Silverlight (XAML) and the Model-View-ViewModel (MVVM) architecture evolved together, thereby affecting each other. In effect, this means that inherent in Silverlight's framework elements and CLR objects are the mechanisms to implement MVVM's loose coupling and separation of concerns. I will go into greater detail on the specific classes and objects in .NET that are primarily involved in hooking everything up further on in this article.

The loose coupling and separation of concerns translates to the ability of large developer teams to work independently on different parts, bringing the pieces together at runtime utilizing classes or object interfaces (as opposed to user interfaces). Another enormous benefit of this is that not only can multiple developers work on different parts of the application simultaneously, designers - for the first time in the history of .NET development - and developers can work on the same code at the same time. Having designers "speaking the same language" as developers solves the longstanding dilemma of a developer taking what the designer gives them and having to rewrite everything to work with the applications. Furthermore, designers - for the first time also - can see what they are doing with data driven controls in the design view in Expression Blend. It's evident that the workflow between professional graphic designers and application developers has been monumentally improved.

Let me back up a bit and give an overview of what MVVM is and does for those of you who aren't familiar with it. MVVM, as architecture, is the mature, successful version of what n-tier attempted to accomplish: quarantine the user interface from the program logic and data. Where Model-View-Controller (MVC) may sufficiently accomplish this goal for ASP.NET applications, MVVM is a refined evolution custom-fit for Silverlight.

There have been intermediate patterns between n-tier and MVVM, all with the same goal, but none of them truly accomplishing the objective until the advent of MVVM and XAML. XAML, being an extension of XML, is inherently tool-able, resulting in the ease of building visual and other editors for those who use it.

If a new Silverlight developer were to dive into a new project without knowing better, they might attempt to put all logic into the codebehind of the MainPage.xaml.cs, as typically has been done in ASP.NET pages. Not only would this lead to difficult testing scenarios, but this methodology doesn't lend itself to long-term maintainability or extensibility. Testing code built like this needs a user interface (UI) to run and a human to debug, which adds to the complexity of finding errors. On the other hand, by using the MVVM architecture, only the "ViewModel" (which will be explained in the next couple of paragraphs) need be tested and verified before ever being bound to the UI.

Properly using MVVM, there is much less codebehind in MainPage.xaml. This is simply pure UI. Each entity in MVVM has its unique tasks, and they do them extremely well with complete separation. MVVM is an acronym for Model-View-ViewModel; let's elaborate on the functionalities of each entity.

At the uppermost level we have the "View". Ideally, the view consists only of the XAML UI and related UI logic. These are the Silverlight screens that are presented to the user. The View's responsibilities are to present data to end users and collect data from end users, period.
At the lowest level we have the "Model". This represents the entities that live on the server as well as the objects that are responsible for interacting with the data stores the application uses along with data persistence. Data interaction in Silverlight can be anything from RIA Services to web services or raw XML. Any CLR-object can be the binding source.

In between these two entities is the "ViewModel". This entity's responsibilities are numerous, but can be summarized as aggregating data that will be bound to the View, retrieved from the Model. This includes methods and states. Since Silverlight doesn't databind to methods, just properties and dependency properties, most of our data logic needs to be in property setters and getters in this ViewModel.

As previously promised, now I'll explain the specific objects in the .NET Framework that are involved in making MVVM and Silverlight work together. The binding mechanism in Silverlight links the View and ViewModel through primarily dependency properties and data context. Each framework element in the View (controls, UI elements, etc.) has a dependency property. These properties can be bound to instances of exposed public properties in the ViewModel. The ViewModel can update the View via the INotifyPropertyChanged interface in the ViewModel base, which is used to discover if the value of the properties have changed by raising the OnPropertyChanged event. This is a two-way conversation that extracts all of the data and logic from the View, but doesn't alter the UI's normal functionalities.

Lastly, I'd like to describe one last tremendous benefit of utilizing this pattern. Because all the logic is in the ViewModel, this entity can be copied from a Silverlight application and inserted into a WPF or Surface application, for instance. This cross-platform extensibility greatly increases return on investment (ROI) for companies that target multiple platforms.

- By Kim Schmidt, Guest Author from the Silverlight Group