In software development there are countless patterns for how to structure your development efforts. MVVM or Model-View-ViewModel is a development pattern based strongly around a separation of concerns in WPF (and Silverlight) applications. For this purpose, applications are broken down into three main components: the View, the ViewModel and the Model.
Working from the top, the View is responsible for what will appear to the user. In this light, a View can be thought of as a template that will display some form of information to the user and handle the user interaction within an application. This could be a submission form, an auction search engine or any other number of possible user-facing scenarios. In many cases, the view will be handled by a designer who specializes in UX (User Experience) but has little to no knowledge about the domain or the business logic going into the application. With that in mind, you would not want to put any complex business code into the view directly. Instead, you want it abstracted away so that the view and business logic can be worked on independently and joined through the rich binding infrastructure present in WPF and Silverlight.
That brings us to the ViewModel, the true workhorse of the application, which contains business logic and otherwise the core of the application. Through databinding, public properties and collections, the ViewModel can be exposed to the View and can even be modified depending on the type of binding (check MSDN for more information on databinding in Silverlight and WPF). This enables a clear separation between the presentation and the logic of the application.
Last, but certainly not least, is the Model. In many scenarios the Model will derive from an ORM system like Telerik Data Access or Entity Framework, but in general the rest of the application is agnostic from the model (often also working with the repository pattern to wrap the ORM for further abstraction). Regardless of where the data is coming from, as long as the ViewModel calls to the right methods and understands the underlying class structure, you have a complete and cohesive application. When these three elements combine you get a fully functional application. The View handles user interaction and displaying information to the user, the Model is responsible for the data of the application and the different CRUD and query operations that are being performed and the ViewModel exists as the glue that combines these two through the Silverlight and WPF databinding engine.
In a world where we have the ability to drag-and-drop a complex control from our toolbox, wire up a few events, receive quick functionality, then move on to the next work item, we sometimes forget that easy software development does not necessarily equate to software that is well structured, easily extensible, and unit testable. MVVM helps with all of these.
When developing with the MVVM pattern, there is a clear distinction between where certain code should exist. Since the View is entirely responsible for presentation, it contains no code (except in cases where the code is very view-specific, although people sit on both sides of that argument) and is only responsible for displaying data and collecting feedback. The ViewModel contains logic that is accessible through binding but will never directly talk to the View. In fact, the ViewModel needs absolutely no knowledge of what View will be hooked up to it. Therefore, if functionality is not working as expected, you can quickly examine the view to ensure binding statements match up; otherwise your ViewModel is segmented and separate and can be tested apart from the UI.
Things brings us to unit testing- the process of testing small ‘units’ of code to ensure that their functionality works as intended. When you utilize the default event-based interaction that is available in Silverlight and WPF, your testing relies on interaction with the UI. In these cases, automated testing definitely comes into play and can be utilized to ensure that your UI remains functional as you work on your application. But before anything ever hits the UI, you want a good amount of certainty that your application will work as expected, leading us to unit testing the code before it ever touches the UI. In order to test each one of the three components separately, you will need to isolate their dependencies to the layer beneath. For example, if you want to test the ViewModel you will need to somehow mock the Model in order to verify the behavior of the ViewModel. This is the place where frameworks like JustMock can help you ease that process.
Another reason for developing in a more modular, segmented approach like MVVM is a combination of extensibility and maintainability. With standard drag-and-drop programming methods you often end up with a cluttered mess of code that is hard to read and even harder to debug. With the MVVM pattern, you have a clear distinction between View code, the business and interaction logic in the ViewModel and the backend interaction that takes place with the Model and the database. If you need to tweak the business logic behind certain operations, you can easily modify the ViewModel and not ever touch the View or the Model. The same goes for Views. If your designer wants to update the look and feel of your application, they can easily replace the views. They just need to ensure that binding statements match between the new View and the public properties and collections on the ViewModel.
At Telerik, we are no strangers to development patterns and practices that emerge in the constantly growing and changing .NET ecosystem. As can be seen from planned increased support for the MVVM pattern in Silverlight 5, even Microsoft has accepted MVVM as the de facto standard for serious enterprise development with Silverlight and WPF. Even before this, the developers at Telerik have been working hard to ensure that all of our components from the UI for WPF, UI for Silverlight and UI for WPF control suites support the MVVM pattern.
Take RadGridView for example. You can always take the easy way and allow RadGridView to generate columns for you based on your datasource but sometimes we want more control over what is being displayed. Looking at the code below, we can see three key parts of MVVM in action with the UI for Silverlight/WPF:
Since we realize that so many different settings require binding to function in an MVVM-based environment, with every release we work to ensure that our controls are as MVVM-compliant as possible and will always support binding scenarios like the above. Two examples of this embedded support for the MVVM pattern are our inclusion of two necessary elements to our assemblies – ViewModelBase and a DelegateCommand Implementation. When using MVVM, one of the things we need to be sure of is ensuring the UI updates according to changes within the ViewModel, so ViewModelBase includes an implementation of INotifyPropertyChanged, allowing us to notify the UI of updates as follows:
DelegateCommand, on the other hand, is an implementation of the iCommand interface that allows for using commands between the View and ViewModel. Since MVVM discourages use of the code-behind file to provide for a more clear separation of concerns, we need some way to enable typical events to populate through to the ViewModel so that the users can interact with your application. As an example of this, we can bind a RadButton to a DelegateCommand from our ViewModel and hook it up to RadGridView using only Xaml and our ViewModel:
Telerik has also created a rich and powerful routed command framework that allows for further codeless interactions with our controls. One great example of this is the RadGridViewCommand, which allow you to fire off commands within RadGridView by use of simple element-to-element binding. To accomplish this, we can use a RadButton with both Command and CommandTarget being set:
While on our ViewModel, all that we need to do is initialize whichever RadGridViewCommands we are going to be using:
Telerik provides two of the basic MVVM gluing elements out-of-the-box: DelegateCommand and ViewModelBase classes located in Telerik.Windows.Controls.dll.We have also developed our own routed command framework, which enables some of the more complex controls to expose commands in order to expose their behavior.