Silverlight View Model - Microsoft Silverlight

What is Silverlight View Model?

In this chapter, we will be looking at an important technique in Silverlight's software development, the use of View Models.

  • The view model is a key piece, which introduces a technique called separated presentation by keeping the view separate from the model.
  • View Models offer one-way of achieving separated presentation, and we will see how they exploit Silverlight's data binding to reduce the amount of code needed in your user interface.

UI Development Challenges

View Models are intended to resolve certain problems that crop up repeatedly when emerging user interface software. Perhaps the most significant one is that user interface code is often problematic to indivisibly test, particularly with automated unit tests. There are also code quality problems that can affect the ongoing elasticity and maintainability of your code.

  • If you follow the path of least opposition that Visual Studio's design tools lead you down, you can end up putting far too much code into the code behind.
  • It is very mutual to see huge amounts of application functionality are added into the code behind.
  • Few designers would really plan to put business logic into a user interface class, but because that is where Visual Studio puts your event handlers, it becomes an all too convenient place to get the things done.
  • It is extensively believed that software is easier to develop and maintain if classes have well-defined and reasonably narrow responsibilities.
  • The code behind's job is to relate directly with the objects that make up the user interface where it is necessary.
  • As soon as you start placing code that makes choices about how your application behaves in there which tends to lead to problems?
  • Not only can application reason flow into code that's hypothetical to be concerned with the user interface, some developers start to rely on controls, and other user interface objects to hold important application state.
  • The model just holds the data, the view only holds the formatted date, and the controller (ViewModel) acts as the liaison between the two. The controller might take input from the view and place it on the model and vice versa.


Separated Presentation

To escape the problems caused by placing application logic in the code behind or XAML, it is superlative to use a method known as separated presentation. Having XAML and code behind with the least required for working with user interface objects directly, a user interface classes also contain code for complex interaction behaviors, application logic, and everything else as shown below on left side.


Vital features of Separated Presentation −

  • With disjointed presentation, the user interface class is much modest. It has XAML of course, but the code behind does as little as is practical.
  • The application logic belongs in a separate class, which is frequently stated to as the model.
  • Many designers try to use data binding to connect elements in the XAML directly to properties in the model.
  • The difficult is the model is completely concerned with matters of what the application does, and not with how the user interacts with the application.
  • Maximum user interfaces have some state that does not feel right in the application model. For instance, if your user interface uses a drag and drop, something needs to keep track of things like where the item being dragged is right now, how its appearance should change as it moves over possible drop targets, and how those drop targets might also change as the item is dragged over them.
  • This sort of state can get astonishingly complex, and needs to be thoroughly tested.
  • In repetition, you usually want some other class sitting between the user interface and the model. This has two important roles.
    • First, it adapts your application model for a particular user interface view.
    • Second, it is where any nontrivial interaction logic lives, and by that, I mean code required to get your user interface to behave in the way you want.

Model / View / ViewModel

View Model is an instance of the separated presentation approach, but let us be clear about precisely what kind of thing we have in each layer. There are three layers −

  • Model
  • View
  • ViewModel


This is a classic object model including of ordinary C# classes that has no direct connection with the user interface.

You would normally expect your Model codes to be able to compile without references to any user interface libraries. In fact, you would probably be able to take the exact same source code and compile it into a Silverlight application, an ordinary .NET Console application, or even server-side web code.

The types in the Model should signify the ideas your application works with.


A View is usually a UserControl, it might be your MainPage, or it might just be some part of your page.

In greatest Silverlight applications, it is a good idea to split your user interface up into small pieces defining a UserControl, or View for each piece.

Silverlight applications are not sole in this respect. Somewhat that is clearly Silverlight specific is the View. The more fine-grained your user interface is, the better things tend to be. Not only are you less probable to trip over other developers working on the same files, keeping things small and simple naturally discourages the shortcuts that lead to spaghetti-like code.

For instance, it is very mutual to define a View to represent an individual item in a List.


Lastly, for each View, you write a ViewModel. So, this is one of the important features of a ViewModel class.

It is to serve a specific View. The ViewModel is specialized for a particular way of offering things, such as a specific data item as it appears in Lists.

This is why it is called a ViewModel; it become accustomed the underlying Model particularly for a particular View. Like the Model, the ViewModel is also an ordinary C# class. It does not need to derive from any particular type.

As it occurs, some developers find it suitable to put some common functionality into a base ViewModel class, but the pattern does not demand that. In particular, your ViewModel does not derive from any Silverlight specific type. However, unlike the model, it can use Silverlight types in its properties.

For instance, your ViewModel might select to make certain parts of your user interface visible only under certain conditions, and so you might provide a property of type System.Windows.Visibility, which is the type Silverlight elements use for their Visibility property. This makes it possible to bind the visibility of an element, such as a panel, directly to the ViewModel.


Let us look at a simple example in which we will be using Model-View-ViewModel (MVVM) approach.
Step 1 −
Create a new Silverlight Application project SilverlightMVVMDemo.
Step 2 − Add the three folders (Model, ViewModel, and Views) into your project as shown below.


Step 3 − Add a StudentModel class in the Model folder and paste the below code in that class.

Step 4 − Add another StudentViewModel class into ViewModel folder and paste the following code.

Step 5 − Add Silverlight User Control by right-clicking on Views folder and Select Add New Item….

Step 6 − Click Add. Now you will see the XAML file. Add the following code into StudentView.xaml file, which contains different UI elements.

Step 7 − Now add the StudentView into your MainPage.xaml file as shown below.

Step 8 − Here is the implementation of Loaded event in the MainPage.xaml.cs file, which will update the View from the ViewModel.

Step 9 − When the above code is compiled and executed, you will see the following output on you webpage.


UI vs ViewModel

  • One of the toughest parts of the MVVM method is working out where the in-between line should come. It is not at all times evident which things belong where.
  • In specific, some user interface elements offer functionality, which, according to a strict View, should arguably belong in the ViewModel.
  • In general, not all behaviors implemented in the View are so ViewModel friendly.
  • Part of the reason for this is that there is not any standard way to package ViewModel behavior for reuse, particularly not if you want to use a design environment, such as Visual Studio, or Blend.

Advantages of MVVM

MVVM deals the next benefits −

  • Separation of Presentation Concerns (View, ViewModel, Model)
  • Clean testable and manageable code. Can include presentation tier logic in unit testing.
  • No code behind code, so the presentation layer and the logic is loosely coupled.
  • Better way of databinding.

Disadvantages of MVVM

For simple UIs, MVVM can be overkill. Debugging would be a bit difficult when we have complex data bindings.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

Microsoft Silverlight Topics