You are already well versed in the purpose of Views by now. A View consists of both a XAML file and a code-behind class. Throughout this book, we have made extensive use of the navigation framework, and in this context, both the XAML file and the class inherit from Page (as discussed back in Chapter 4, "The Navigation Framework"). However, this is of no consequence and has no impact on the implementation of the pattern. You may choose use Prism, or perhaps no framework at all. For the purpose of the examples in this chapter however, we will assume you are using the navigation framework for structuring and composing your user interface.

Theoretically, when using MVVM, the View's code-behind class should be considered essentially irrelevant, with little to no code written in that class. Instead, any logic and behavior for the View should be placed in the ViewModel class (where possible), leaving the code-behind class empty, a goal often referred to as "zero code-behind".

The View will pull data from the ViewModel, using the extensive data-binding capabilities provided by Silverlight/XAML. Any events that the View wants to raise (to be handled by a method defining some behavior or logic in the ViewModel) can either be published as a command (that the ViewModel can subscribe to), or an action or behavior can be used to call a method on the object assigned to the View's data context (which will be the ViewModel).

A Model is an object, usually containing data (obtained from the server) for use by the View. When you are making use of RIA Services to communicate with the server, your Model objects will be the entities (objects) returned by a domain service.

Although the View and the Model both leverage existing components that you are already familiar with, the ViewModel is an entirely new piece to the puzzle. View Models are used to maintain the state of a View. In this, they have a dual purpose—to expose data to the View and to handle the View's logic and behavior, essentially serving the needs of the View.

Although its name may indicate that the purpose of a ViewModel is to provide a View of the Model (abstracting the Model for consumption by the View), it's really the other way around. The ViewModel is used to maintain the state of the View and, therefore, should be considered a Model of the View. That state will be maintained within the ViewModel (exposed as properties), with operations (exposed as methods) that can be invoked by a command or an action or behavior from the View (usually in response to a control event). The View will then bind to this ViewModel to consume the data that it exposes and invoke operations on it (generally in order to trigger a change in the View's state, represented by the ViewModel).

By exposing both the data (via properties) and the logic or behavior (via methods) publicly from the ViewModel class (enabling their consumption by the View), the ViewModel also becomes inherently testable. Ideally, therefore, all the behavior and logic for a View (that can't be handled in the View's XAML) should be placed in its corresponding ViewModel, leaving minimal (if any) code in the View's code-behind.

For example, you may have one ViewModel that serves multiple Views; a wizard is a good example of where this might be required. However, this would require a slight alteration to our diagram, as when implementing this configuration (generally), the ViewModel will be responsible for creating the View and will therefore know about the View. This factors into the ViewModel-first debate, which will be discussed later in this chapter.

In turn, a single View may interact with multiple ViewModels. Instead of having the ViewModel exposing Model objects directly to the View, some developers choose to wrap their Model objects in ViewModels, abstracting the Model from the View. Instead of the View binding directly to the data (i.e., the Models), it will bind to a ViewModel instead.

For example, a View may populate a list box with a collection of ProductViewModel objects, with each wrapping a Product Model object. These ViewModels could essentially be considered a view of the Model. Additional properties, calculations, logic, etc, could be added to these ViewModel objects (serving the needs of the View), saving the Model from being polluted with View-related requirements.

The big issue with the practice of wrapping all your Model objects in ViewModels is the amount of overhead and additional code required to wrap each of the Model objects in a ViewModel, often resulting in properties on the ViewModel that purely exist to relay property values from the Model objects. Most of the time the outcome of this practice is simply an unnecessary duplication of code. Therefore, whether you undertake this practice will generally be on a case-by-case basis.

By now, you will be familiar with creating new Views using the navigation framework. We'll create a simple View for this example consisting of two text boxes (with corresponding labels) for the user to enter a user name and password into and a button that will initiate the user authentication check on the server, as per the following XAML:

<navigation:Page x:Class="Chapter12Sample.Views.LoginView"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      xmlns:navigation="clr-namespace:System.Windows.Controls; 

assembly=System.Windows.Controls.Navigation"
      xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk"
      mc:Ignorable="d" Title="Login">

  <Grid x:Name="LayoutRoot" Background="White" Width="300" Height="110">
    <Grid.ColumnDefinitions>
      <ColumnDefinition Width="90" />
      <ColumnDefinition Width="*" />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
      <RowDefinition Height="35" />
      <RowDefinition Height="35" />
      <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <sdk:Label Content="User Name:" Margin="5,0"
          HorizontalContentAlignment="Right" />
    <sdk:Label Content="Password:" Margin="5,0"
          HorizontalContentAlignment="Right" Grid.Row="1" />

    <TextBox Grid.Column="1" Name="UserNameTextBox" Height="25" />
    <TextBox Grid.Column="1" Grid.Row="1" Name="PasswordTextBox" Height="25" />

    <Button Content="Log In" Grid.Column="1" Grid.Row="2" Height="30" Width="90"
        HorizontalAlignment="Right" VerticalAlignment="Top"
        Name="LoginButton" Margin="0,5,0,0" />
  </Grid>
</navigation:Page>

This gives you the View layout shown in Figure 12-2.

Figure 12.2. The login View

For the purposes of this example, where we are primarily concerned with the interaction of the View and the ViewModel, we'll be disregarding the Model from the equation to keep things simple. However, this would (in practice) be a user object such as the User entity returned from RIA Services.

While implementing the previous two layers (containing the Views and Models) will be familiar to you, the ViewModel is a new piece that you will need to implement in the puzzle that is MVVM. As mentioned previously, ViewModels expose data to the View as properties and operations as methods.

Usually, your ViewModels will inherit from a base class (e.g., ViewModelBase) that provides common functionality required by all the ViewModels in your project. At a minimum, this base class will implement the INotifyPropertyChanged and the INotifyDataErrorInfo or IDataErrorInfo interfaces (as was discussed back in Chapter 7, "Building Data Entry Forms"). If you make use of a MVVM framework, this base class will generally be provided as a key part of the framework. The sample code accompanying this chapter contains a simple base ViewModel that you could alternatively use, as per Figure 12-3.

What other properties will be created on your ViewModel will depend on the strategy you have chosen to take for exposing data from Model objects to your View. Each property from the Model that should be available to the View might have a corresponding property on the ViewModel (which the View can bind to), or you may simply return the Model object directly to the View for its consumption. In this simple example, we don't need to consume data from Model objects in our View, but we'll look further at this scenario of consuming data using the MVVM design pattern later in this chapter when we discuss its use in conjunction with RIA Services.

The class diagram of the ViewModel that we will use for this example is shown in Figure 12-3.

Figure 12.3. The LoginViewModel class and the ViewModelBase class

There's nothing special about the way that the Model objects are connected to the ViewModel; often, the ViewModel will hand off the tasks to a service agent that handles retrieving/instantiating them and then returns them to the ViewModel. It can then retain a reference to these objects for future use.

However (assuming you are using RIA Services to obtain the data from the server), you will remember from Chapter 6, "Implementing Summary Lists," that there are two methods you can use to communicate with the domain services on the server. You can use the DomainDataSource control, or you can use the data context object directly. The DomainDataSource control is designed for use in Views, and thus would completely bypass the ViewModel if you were to use it, a violation of the MVVM design pattern. Hence, when implementing MVVM, you should communicate with a domain service from the ViewModel using its corresponding data context directly (which acts as a service agent).

The ViewModel is connected to the View by way of having an instance of it assigned to the DataContext property of the View, enabling properties of the controls in the View to bind directly to properties on the ViewModel.

However, how this ViewModel instance is instantiated can vary greatly and is one of the more hotly debated implementation details of the pattern. We'll discuss these methods further later in this chapter, but for now, we will be taking the approach in which the View is responsible for instantiating the ViewModel.

You generally instantiate the ViewModel either within the View's XAML or its code-behind. To be able to do so in XAML, the XAML parser requires the ViewModel to have a parameterless constructor. If this is not possible (e.g., the View needs to pass the ViewModel the ID of an entity to load), you will have to instantiate it from the code-behind instead.

For example, instantiating a ViewModel in XAML and assigning it to the DataContext property of the View can be done as follows:

<navigation:Page x:Class="Chapter12Sample.Views.LoginView"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
      xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
      xmlns:navigation="clr-namespace:System.Windows.Controls; 

               assembly=System.Windows.Controls.Navigation"
      xmlns:vm="clr-namespace:Chapter12Sample.ViewModels"
      mc:Ignorable="d" Title="Login">
  <navigation:Page.DataContext>
    <vm:LoginViewModel />
  </navigation:Page.DataContext>

  <Grid x:Name="LayoutRoot">
    <!-- Removed for the purpose of brevity -->
  </Grid>
</navigation:Page>

Alternatively, to do the same in the constructor of the class in the code-behind would be implemented like so:

this.DataContext = new LoginViewModel();

By now, you should be fairly familiar with the power of Silverlight's data-binding capabilities and how to take advantage of them in your applications. The ViewModel maintains the View's state (which is exposed as properties), and bindings (defined within the View) provide a two-way connection bridging the boundary between the View and the ViewModel. This enables the View to consume the data from the ViewModel and update the ViewModel again with any changes made to the data in the View (via the two-way data binding connection demonstrated in Figure 12-4).

Figure 12.4. The interaction between the View and the ViewModel using bindings

The Text property of both text boxes in our View will be bound to properties on the ViewModel (using two-way binding). The Text property of the UserNameTextBox text box in the View will be bound to the UserName property on the ViewModel, and the Text property of the PasswordTextBox text box in the View will be bound to the Password property on the ViewModel, like so:

<TextBox Grid.Column="1" Name="UserNameTextBox" Height="25"
     Text="{Binding UserName, Mode=TwoWay}" />
<TextBox Grid.Column="1" Grid.Row="1" Name="PasswordTextBox" Height="25"
     Text="{Binding Password, Mode=TwoWay}" />

One issue that you may have is when you need to bind a control (such as a ListBox or a DataGrid) in the View to a collection exposed from the ViewModel (as a property) but don't have that collection available at the time that the ViewModel is instantiated. For example, say you need to bind a ListBox control in the View to a collection of objects exposed by the ViewModel. However, the ViewModel doesn't have that collection available when it is instantiated, as it has to go off and retrieve the collection from the server. How do you handle this problem?

The answer is to have the ViewModel expose the collection as a property of type ObservableCollection. When the ViewModel is instantiated, an empty ObservableCollection should be instantiated and made available to the View for the ListBox control to bind to. Then when the collection has been retrieved from the server, its contents should be added to the empty ObservableCollection collection (instead of replacing it), which (as we discussed back in Chapter 6, "Implementing Summary Lists") the View is listening to for changes and updates accordingly as the data becomes available.

Operations (containing logic and behavior) will be exposed from your ViewModel as public methods. For example, in our login screen scenario, we have a BeginLogin method in the ViewModel and a Login button in the View. The BeginLogin method needs to be invoked in response to the user clicking the Login button in the View (hence the method should be invoked in response to the Click event of the button being raised).

There are three ways you can invoke an operation on a ViewModel in Silverlight:

Invoking the operation in the code-behind is the traditional solution to this problem, but it doesn't typically conform to the MVVM way of interacting between the View and the ViewModel. Therefore, we'll look instead at how to implement the other two methods now (as pictured in Figure 12-5).

Figure 12.5. The interactions of the View invoking an operation on a ViewModel

<Button Name="LoginButton" Content="Log In" Height="30" Width="90">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
                <ei:CallMethodAction TargetObject="{Binding}"
                  MethodName="Login"/>
    </i:EventTrigger>
  </i:Interaction.Triggers>
</Button>

Commands

Commands are a new topic that we haven't yet discussed thus far in this book. In essence, commands provide a means for encapsulating an operation and its parameters away from the ViewModel. The logic for the operation is moved outside the ViewModel and into its own class (but acting upon the ViewModel), decoupling the logic from the ViewModel state and enabling the logic to be reused. For example, you may have a login operation that can be invoked by two different ViewModels. Commands allow you to encapsulate this login logic and reuse it.

You may also like to think of commands as providing a means to bind to operations (as opposed to data). The command is exposed from the ViewModel as a property, enabling controls to bind to it and to invoke it in response to a given event.

Note

Commands aren't strictly a part of the MVVM design pattern (being a design pattern of their own) but are commonly used to support the MVVM design pattern.

Creating a Command

For example, our Login method could be encapsulated in a command class and invoked when the Login button is clicked. To create a command class, it must implement the ICommand interface, as shown in Figure 12-6.

Figure 12.6. The ICommand interface

The CanExecute property specifies whether or not the command can be executed. When the command is bound to a button, the button will be enabled or disabled accordingly. In order for the button's enabled status to update when the property updates, the CanExecuteChanged event on the command should be raised. Any logic to be executed when the command is executed will go in the Execute method.

Note

It's a common problem to forget to raise the CanExecuteChanged event after changing the value of the CanExecute property. If you find that your button is disabled despite having updated the value of the CanExecute property, this is most likely the source of the issue.

To create a simple command, create a new class named LoginCommand and implement the ICommand interface.

public class LoginCommand : ICommand
{
  public bool CanExecute(object parameter)
  {
    return true; // Alternatively, provide some logic here
  }

  public event EventHandler CanExecuteChanged;

  public void Execute(object parameter)
  {
    // Your command's logic goes here
  }
}

The next step is to expose this command from your ViewModel as a property (to make it available to the View). To do so, add the following property to your ViewModel:

private ICommand _loginCommand = new LoginCommand(); // Member variable

public ICommand Login
{
  get { return _loginCommand; }
}

Note

Often when implementing a command in this manner, you will pass an instance of your ViewModel or an object to its constructor for the command to perform the operation upon. Alternatively, you might pass the ViewModel or the object to the command as a parameter, as will be discussed shortly.

Invoking a Command

Although the ICommand interface was available in Silverlight 3, there was no support provided for invoking commands by any controls until Silverlight 4 (i.e., there were no Command and CommandParameter properties on any controls). Therefore, to invoke a command in response to an event raised by a control in Silverlight 3, you had to use the InvokeCommandAction action from the Expression Blend Interactivity library.

Silverlight 4 has added limited support for invoking commands, but only those implemented on the ButtonBase class, which can now invoke a given command when its Click event is raised. ButtonBase isn't designed to be used directly, but it acts as the base class for the Button, HyperlinkButton, ToggleButton, and RepeatButton controls, all of which inherit this behavior.

To invoke a command in response to a button click, you bind the control's Command (and optionally CommandParameter) properties to the property on the ViewModel that exposes the command. In our login screen scenario, this means we can now bind the Command property of the Login button in the View to the Login property on the ViewModel, which will invoke the command when the button is clicked:

<Button Command="{Binding Login}" Content="Log In" />

Note

Unfortunately no other controls have support for commands in Silverlight, but you can still use the InvokeCommandAction action to invoke a command in response to any event they raise (such as in response to an item in a ListBox control being selected).

The DelegateCommand

If you are more interested in the ability to bind to operations than moving the logic for an operation outside the ViewModel, you may wish to consider implementing a DelegateCommand. This command is designed to enable you to keep your operation methods within your ViewModel but still be able to expose them as command properties and bind to them without needing to create a class for each command. This results in making the implementation of commands much simpler.

An example of implementing a command on you ViewModel as a DelegateCommand (which is being used to call a method named BeginLogin on the ViewModel) follows:

// Member variable
private ICommand _loginCommand = DelegateCommand(BeginLogin, CanLogin);

public ICommand Login
{
  get { return _loginCommand; }
}

public void BeginLogin(object param)
{
  // Operation logic goes here
}

private bool CanLogin(object param)
{
  if (param != null && param.GetType() == typeof(bool))
    return (bool)param;
  else
    return true;
}

As you can see, rather than creating a separate command, we are simply instantiating an instance of the DelegateCommand class and passing it the method on the ViewModel to call when the command is invoked and a method with the logic specifying whether the command is allowed to be invoked.

Unlike WPF, Silverlight 4 doesn't have any ICommand implementations (like the DelegateCommand command) built in, but you can implement your own. You can find the code for an implementation of the DelegateCommand command in the sample code accompanying this chapter and use that in your project. You will also find an implementation of the DelegateCommand command in Prism (see the "Frameworks" section later in this chapter).

Note

Another popular alternative to the DelegateCommand is the RelayCommand. An implementation of the RelayCommand command can be obtained from the MVVM Light Toolkit (one of the popular MVVM frameworks for Silverlight, which you will find listed in the "Frameworks section" later in this chapter).

Passing a Parameter to a Command

You can pass a parameter through to the Execute method of the command if you wish. This will be assigned to the CommandParameter property of the button, and its value will be passed into both the CanExecute method and the Execute method when the button is clicked.

For example, you can bind this property to a property on another control (such as the SelectedItem property on a ListBox control), and the value of that control's property will be passed to the Execute method of the command as its parameter. Alternatively, you can bind it to an object exposed by your ViewModel (or the ViewModel itself) for it to perform the operation on.

The following example demonstrates passing the ViewModel to the command as a parameter (assuming that the DataContext property of the Button control has been assigned the ViewModel instance):

<Button Command="{Binding Login}" CommandParameter="{Binding}" Content="Log In" />

Looking at the other side of the coin now, how does the ViewModel notify the View that something has happened (to which it may wish to respond)? Exposing properties that elements in the View can bind to will suit some scenarios, but what if you need the View to respond to a notification from the ViewModel (such as when it raises an event)?

This is particularly important in Silverlight, where all calls to the server are asynchronous. In our login screen scenario, we ask the ViewModel to authenticate the user (by calling a method or invoking a command on the ViewModel) but don't know the result when the method returns. Instead, an event handler is called on the ViewModel when the response from the server has been received, and we then need the View to respond accordingly. If the user was successfully authenticated, the View should navigate away from the login screen to the next View (such as a dashboard screen). If the authentication failed, the screen should display a message to the user notifying them of the failure.

We can implement this behavior by raising events (one for when the authentication is successful and another for when it fails) from our ViewModel and implement triggers in the View that listen for these events and respond accordingly (as per Figure 12-7).

Figure 12.7. The interaction of the View handling notifications from the ViewModel

In our example ViewModel, we have defined three events:

Let's look at implementing the LoginSuccessful event. In your ViewModel, you can raise this event in the standard way:

if (LoginSuccessful != null)
  LoginSuccessful(this, new EventArgs());

Now, in your View, you can use the EventTrigger trigger and listen for the LoginSuccessful event to be raised on the ViewModel. It can then perform an action in response (which for this scenario will require a custom action named NavigateAction to navigate to a given View), as demonstrated here:

<i:Interaction.Triggers>
  <i:EventTrigger SourceObject="{Binding Mode=OneWay}"
          EventName="LoginSuccessful">
    <mvvm:NavigateAction Url="/Dashboard" />
  </i:EventTrigger>
</i:Interaction.Triggers>

As discussed earlier in this chapter, some developers like to keep a clean separation between the View and the Model layers, wrapping the Model objects in ViewModels before exposing them to the View. From a pure design perspective, ideally the View should know nothing about the Model objects and interact only with the ViewModel objects (keeping the View and the Model layers completely decoupled).

However, from a practical perspective, wrapping your Model objects in ViewModels adds additional overhead, increases the amount of code and the complexity, and reduces maintainability. Ultimately, it's generally best (depending on the scenario) to simply expose your Model objects (or collections of Model objects) directly to the View via a property on the ViewModel.

If you have chosen to not expose your Model objects directly to the View (exposing the data via a ViewModel instead), you will need to decide between these options:

This question has two parts and can be asked in regard to both the design and to the instantiation of the View and ViewModel. Whether you design the View or the ViewModel first will really depend on your development practices.

However, how the View and the ViewModel are instantiated is a more important question. We've demonstrated throughout this chapter that the View creates the ViewModel, and hence, the View maintains ownership over the ViewModel, with the ViewModel simply serving the View's needs (but without actually knowing anything about it).

A number of frameworks are available that can provide additional support for structuring your application using the MVVM design pattern (as discussed later in this chapter). However, some developers believe that you are better off rolling your own and that it's not necessary or worthwhile to implement a major framework. To properly grasp the principles of MVVM and identify if and where a framework can help you (without becoming too overwhelmed by all their features), it's probably best that you start off (in a small test project) without using a framework but investigate the available options when implementing a major project. Many of the popular frameworks go beyond simply supporting the MVVM design pattern and add a lot of helpful infrastructure to your project, so they are well worth looking into.

Whether you implement dependency properties or standard properties in your ViewModel ultimately comes down to personal preference. Because you are binding to the properties (which act as the source of the data), they don't have a need to be dependency properties (as opposed to developing custom controls where their properties can be bound to an object, hence acting as the consumer of the data).

Therefore, as a general rule, standard properties that raise the PropertyChanged event (from the INotifyPropertyChanged interface) are the best choice for implementing properties in ViewModels.