Part 2 of a series describing the creation of a Silverlight business application using MEF, MVVM Light, and WCF RIA Services. In this second part, we will go through various topics on how MVVM Light Toolkit is used in our sample application.

Contents

Introduction

In this second part, we will go through various topics on how the MVVM Light Toolkit is used in our sample application. I chose this toolkit
mainly because it is lightweight. Also, it is one of the most popular MVVM frameworks supporting Silverlight 4.

RelayCommand

One of the new features in Silverlight 4 is a pair of properties added to the ButtonBase class named Command and
CommandParameter. This commanding infrastructure makes MVVM implementations a lot easier in Silverlight. Let's take a look at how
RelayCommand is used for the "Delete User" button from the User Maintenance screen. First, we define the XAML code of the button as follows:

The code above specifies that we should call the RemoveUserCommand defined in UserMaintenanceViewModel.cs
and pass in a parameter of the currently selected user when the "Delete User" button is clicked. And, the RelayCommand RemoveUserCommand is defined as:

The code snippet above, when called, will first display a message asking to confirm whether to delete the selected user or not. If confirmed, the functions
RemoveUser() and SaveChangesAsync(), both defined in the IssueVisionModel class, will get called, thus removing the selected user from the database.

The second parameter of the RelayCommand is the CanExecute method. In the sample code above, it is defined as "g => (_issueVisionModel != null) &&
!(_issueVisionModel.HasChanges) && (g != null)", which means that the "Delete User" button is only enabled when there are no pending changes
and the selected user is not null. Unlike WPF, this CanExecute method is not automatically polled in Silverlight when
the HasChanges property changes, and we need to call the RaiseCanExecuteChanged method manually, like the following:

Messenger

The Messenger class from MVVM Light Toolkit uses a simple Publish/Subscribe model to allow loosely coupled messaging. This facilitates
communication between the different ViewModel classes as well as communication from the ViewModel class to the View class. In our sample, we define a static
class called AppMessages that encapsulates all the messages used in this application.

In the code-behind file MainPage.xaml.cs, four AppMessages are registered. ChangeScreenMessage is
registered to handle requests from the menu for switching between different screens. The other three AppMessages are all system-wide messages:

RaiseErrorMessage will display an error message if something goes wrong, and immediately logs off from the database.

PleaseConfirmMessage is used to display a message asking for user confirmation, and processes the call back based on user feedback.

StatusUpdateMessage is used to update the user on certain status changes, like a new issue has been successfully created and saved, etc.

EventToCommand

EventToCommand is a Blend
behavior that is added as a new feature in the MVVM Light Toolkit V3, and is used to bind an event to an ICommand directly in XAML, which gives
us the power to handle pretty much any event with RelayCommand from the ViewModel class.

Following is an example of how drag and drop of files is implemented in the "New Issue" screen. Let's check the XAML code first:

The code above basically specifies that the ListBox allows drag-and-drop, and when a Drop event fires,
the HandleDropCommand from the IssueEditorViewModel class gets called. Next, let's look at how HandleDropCommand is implemented:

HandleDropCommand will loop through the list of files dropped by the user, reads the content of each file, and then adds them into the
FilesEntityCollection. The data will later be saved to the database when the user saves the changes.

ICleanup Interface

Whenever the user chooses a different screen from the menu, a ChangeScreenMessage is sent, which eventually calls the following OnChangeScreenMessage method:

From the code above, we can see that every time we switch to a new screen, the current screen is first being tested to see whether it supports the
ICleanup interface. If it is, the Cleanup() method is called before switching to the new screen. In fact, any screen, except the Home screen
which does not bind to any ViewModel class, implements the ICleanup interface.

The Cleanup() method defined in any of the View classes will first call the Cleanup() method on its ViewModel class to unregister any event handlers
and AppMessages. Next, it will unregister any AppMessages used by the View class itself, and the last step is to release the ViewModel class by calling
ReleaseExport<ViewModelBase>(_viewModelExport), thus making sure that there are no memory leaks. Let's look at an example:

Next Steps

In this article, we visited the topics of how the MVVM Light toolkit is used: namely, RelayCommand, Messenger,
EventToCommand, and ICleanup. In our last part, we will focus on how custom authentication, reset password, and user maintenance are done through WCF RIA Services.