Creating a new RoutedUICommand is a simple instantiation, as the code in Listing 4-3 shows.

public static RoutedUICommand SaveCommand =
   new RoutedUICommand("Save","SaveCommand",
   typeof(UIElement) );

The first parameter in the constructor populates the Text property, the second parameter is the name used in serialization of the command (I usually append Command to the text from the first parameter), and the last parameter is the UIParent. (In this example, the code states any UIElement can be the parent.) There is a fourth parameter in another Constructor (not shown here) that is a list of InputGestures.

Custom RoutedUICommands are usually created as static variables so there is only once instance (and it makes binding simpler). Yes, it's still in the code-behind file, so we don't yet have Separation of Concerns, but we're getting there!

Unlike the built-in commands (which are part of the framework and automatically wired into the CommandManager and the binding system), custom commands are not. Three changes need to be made in the XAML to support custom commands:

As Chapter 1 explains, you can add custom namespace declarations to the Window to allow XAML access to custom classes and namespaces. The namespace for the custom command (which is the same namespace as the Window if the command is a static variable in the code-behind) needs to be added to the Window tag. Listing 4-4 shows an example namespace declaration. The bolded text is what has changed from the default namespace declarations that are in the standard WPF Window.

<Window x:Class="Chapter4.Commands.CommandBindingSample"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/
        presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:Commands="clr-namespace:Chapter4.Commands"
        Title="Command Binding" Height="122" Width="261">

After the namespace is brought into the Window, the command must be inserted into the Window.CommandBindings collection. Three main properties need to be set and are shown in Listing 4-5:

With built-in commands, a simple string assigned the command to the UIElement. With custom commands, you have to use a binding expression (as discussed in Chapter 3). The format for a static command binding is

{x:Static NamespaceReference:Class.CommandVariableName}.

The NamespaceReference is the nickname assigned in the Window tag. Interestingly, the CanExecute and Executed properties are set to the name of the methods — no funky binding required!

<Window.CommandBindings>
  <CommandBinding Command="{x:Static
   Commands:CommandBindingSample.SaveCommand}"
   CanExecute="Save_CanExecute"
   Executed="Save_Executed"/>
</Window.CommandBindings>

The Command property of the CommandBinding and UIElements use the same binding expressions as shown in Listing 4-6. When a UIElement has a command bound to it, the framework looks for the first match in the CommandBindings section up the element tree. When one is located, the UIElement uses the assigned event handlers CanExecute and Execute.

<MenuItem Command="{x:Static
   Commands:CommandBindingSample.SaveCommand}"/>
<Button Command="{x:Static
   Commands:CommandBindingSample.SaveCommand}"
   Content="{Binding RelativeSource={RelativeSource
   Mode=Self}, Path=Command.Text}"/>

The CanExecute event handler for a Routed[UI]Command uses the CanExecuteRoutedEventArgs instead of returning True or False. Setting e.CanExecute to True (can run) or False (cannot run) will enable or disable the command (and any associated UIElements).

If the command is enabled, the Executed event handler gets executed when the UIElement triggers the command (for example, when a button is clicked).

The CanExecuteRoutedEventArgs and ExecutedRoutedEventArgs contain a Parameter property that provides a mechanism for passing objects from the Window into the CanExecute and Executed event handlers. For the example in Figure 4-5, the text of the TextBox is being passed as the parameter. The CanExecute property of the CanExecuteRoutedEventArgs in the CanExecute event handler is set to False if the string is empty or null, and the Executed event handler displays it back to the user in a message box. Okay, not a realistic example, but it's a demo!

Listings 4-7 and 4-8 show passing a parameter into the command through XAML and then using that parameter in the C# implementation of the events.

<Button Command="{x:Static
   Commands:CommandBindingSample.SaveCommand}"
   CommandParameter="{Binding ElementName=txtField,
   Path=Text}"
   Content="{Binding RelativeSource={RelativeSource
   Mode=Self}, Path=Command.Text}"/>

private void Save_CanExecute(object sender,
   CanExecuteRoutedEventArgs e)
{
  e.CanExecute = !String.IsNullOrEmpty(e.Parameter as
   string);
}
private void Save_Executed(object sender,
   ExecutedRoutedEventArgs e)
{
  MessageBox.Show(e.Parameter.ToString());
}

Figure 4-5. Custom routed UI command.

Custom RoutedUICommands solve the problem of getting rid of all those nasty OnClick event handlers, consolidating execution code into one event handler and bringing along the goodness of the CanExecute event handler to enable a more dynamic and intuitive user interface.

To truly achieve Separation of Concerns by removing the implementation from the code behind, implement the commands from the ground up starting with the ICommand interface. The interface for ICommand contains the CanExecute and the Executed event handlers as well as the CanExecuteChanged event.

The code in Listing 4-9 shows an example custom Save command. There are some differences to consider:

public class CustomSaveCommand : ICommand
{
    public string Text { get; set; }
    public CustomSaveCommand(string text)
    {
        Text = text;
    }
    public void Execute(object parameter)
    {
        //Insert Actual "Save" code here
        //Display feedback message to user
        MessageBox.Show(parameter.ToString());
    }

    public bool CanExecute(object parameter)
    {
        return !String.IsNullOrEmpty(parameter as string);
    }

    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }
}

In the sample, the custom command is instantiated through a static property in the code-behind the same way the custom RoutedUICommand was in the preceding example. The next section details a much better way to handle exposing the commands to the XAML.

The first unit test verifies that the Text property of the instantiated command gets populated in the constructor. The complete unit test is shown in Listing 4-10. The Arrange, Act, and Assert comments are not usually included in the unit tests. They are included in Listing 4-10 to demonstrate the structure of a unit test.

To execute the test, run Gallio Icarus — the GUI test runner that ships with Gallio. Click on Add Files, navigate to your compiled test project, and then click on Start to run the tests.

[Test]
public void Should_Set_Text_Property_In_The_Constructor()
{
    //Arrange
    CustomSaveCommand command;
    //Act
    string expectedValue = "Save";
    command = new CustomSaveCommand(expectedValue);
    //Assert
    Assert.AreEqual(expectedValue, command.Text);
}

When writing unit tests, it's important to test success as well as failure conditions. For the CanExecute method of the custom Save command, that means tests must cover when the parameter is null or empty in addition to having a string value. These tests are shown in Listing 4-11.

[Test]
public void Should_Not_Execute_If_Parameter_Is_Null()
{
    ICommand command = new CustomSaveCommand("Save");
    bool canExecute = command.CanExecute(null);
    Assert.IsFalse(canExecute);
}
[Test]
public void Should_Not_Execute_If_Parameter_Is_Empty_String()
{
    ICommand command = new CustomSaveCommand("Save");
    bool canExecute = command.CanExecute(string.Empty);
    Assert.IsFalse(canExecute);
}
[Test]
public void Should_Execute_If_Parameter_Is_Not_Empty_String()
{
    ICommand command = new CustomSaveCommand("Save");
    bool canExecute = command.CanExecute("Test");
    Assert.IsTrue(canExecute);
}

The DAL is the set of classes and methods that get the data out of the data store (such as SQL Server) and populate the Model (see next item). It is also responsible for persisting any changes to the data back to the data store.

The Model is the data that composes your application — not the data store itself (for example, the database), but the object graph that represents the data for your application. In a sales application, example objects could be classes like Customer, SalesRegion, and SalesPerson.

The BL is the implementation of the business rules for the application. This layer ensures that the data in the Model adheres to the law of the land.

The View represents the pieces of the application that interact with the user. For WPF, this is the collection of Windows that compose the application.

The biggest gap with displaying an object graph (Model) in a View is that applications seldom display only one type of object at a time. If the Window allows for editing a customer, then it probably needs to display the sales regions, sales people, and so forth.

Combining multiple objects into a data object clouds the Model, and placing all that code into the view places too much knowledge in the View — not to mention a total testability fail. The compilation of the required parts of the object graph should not detract from any other part of the application.

The Command Objects are another consideration. There isn't a tidy place in the traditional application layers to place the custom commands. The code contained in the commands is (typically) Business Logic, but the Window needs to bind to the commands, and is therefore specific to the View.

The ViewModel fills that gap. It is designed to be a single class that pulls in all the necessary data points and commands into a one-stop shop for a particular view. Each view typically has its own ViewModel, but that is entirely dependent on your particular application.

As Chapter 3 discusses, WPF automatically monitors any class that implements either INotifyPropertyChanged (for items bound to a property of a class) and/or INotifyCollectionChanged (for items bound to a collection of items). These interfaces should be implemented in one of two camps — the ViewModel or the Model.

Implementing those two interfaces in the ViewModel is the more academic, textbook implementation. This is because it separates user interface code from the Model. It also requires a lot of additional work, because it entails recoding all the properties and collections of your Model to include raising the proper events.

Implementing in the Model reduces work, because it merely entails adding a few lines of code into properties already being implemented in the classes. A main argument against Model implementation revolves around code reuse. For example, if the Model is also used by an ASP.NET application, those events are still raised but no one is listening. This could potentially present a performance issue. Of course, if you use the same model for WPF and non-WPF Views, then a simple flag passed into the constructor of the Model classes indicating whether the events should be raised or not resolves that issue.

Both ways are valid implementations. Your application and specific situation will most likely dictate where those interfaces are implemented.

In Chapter 3, you discover that if a control doesn't have an explicit DataContext, it is inherited from the closest parent in the control tree that does have a DataContext explicitly assigned.

When developing WPF applications using the ViewModel pattern, the instantiated ViewModel becomes the Window's (or user control's) DataContext.

The Window (or View, to use "architecture speak") is a simple customer maintenance form. The user can select a customer and edit his name and sales region. Clicking the Add Customer button will add a customer to the list. You're right — not very realistic, but it demonstrates the ViewModel principles. Figure 4-6 shows the completed sample user interface.

Figure 4-6. The Customer Maintenance Window.

Okay, enough talk. For the sample ViewModel, we need to define a Model.

Listing 4-12 shows the base class from which all the Model classes will derive. The base class implements the INotifyPropertyChanged interface as well as the IsDirty property.

public class ModelBase : INotifyPropertyChanged
{
    public bool IsDirty { get; private set; }
    public event PropertyChangedEventHandler PropertyChanged;
    internal void NotifyPropertyChanged(object sender, string
   propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(sender, new PropertyChangedEventA
   rgs(propertyName));
        }
        IsDirty = true;
    }
}

Listings 4-13 and 4-14 show the Customer and SalesRegion classes that will populate the View. For each property in the class (except for the primary key and the collection properties), there is a check to see if the value of the property is being set to a new value. If it is new, then the PropertyChanged event is raised. The NotifyPropertyChanged method also sets the IsDirty flag to True to indicate that the model has changes that need to be persisted.

The primary key (in this example) is being set by the data store, so it will never change in the view. Because the property changed event will never need to be raised, the property can be coded as an automatic property.

public class Customer : ModelBase
{
    private string _name;
    private SalesRegion _region;
    public int ID { get; set; }
    public string Name
    {
        get { return _name; }
        set
        {
            if (value == _name)
            {
                return;
            }
            _name = value;
            NotifyPropertyChanged(this, "Name");
        }
    }
    public SalesRegion SalesRegion
    {
        get { return _region; }
        set
        {
            if (value == _region)
            {
                return;

}
            _region = value;
            NotifyPropertyChanged(this, "SalesRegion");
        }
    }
}

public class SalesRegion:ModelBase
{
    private string _name;
    public int ID {get; set;}
    public string Name
    {
        get { return _name; }
        set
        {
            if (value == _name)
            {
                return;
            }
            _name = value;
            NotifyPropertyChanged(this, "Name");
        }
    }
}

There isn't much to test in the model. You don't typically write tests against the .NET Framework itself — one has to assume that it works! The only real logic in this sample is setting of the IsDirty and the raising of the PropertyChanged event when something changes.

The first test is to verify that the IsDirty flag gets set when a property changes, and it is very straightforward. We create a new Customer, assert that the IsDirty flag is False, make a change, and then assert that the IsDirty flag is True. This test is shown in Listing 4-15.

[Test]
public void Should_Set_Is_Dirty_On_Property_Change()
{
    var sut = new Customer();
    Assert.IsFalse(sut.IsDirty);
    sut.Name="New Name";
    Assert.IsTrue(sut.IsDirty);
}

The second test is much more involved, because it tests the raising of the PropertyChanged event. We have to create a subscriber to listen for this event. Windows (and the WPF rendering engine) automatically attach to this event, but we don't want to re-create the rendering engine just to test one method. To test the event, create a subscriber, raise the event, and then assert that the handler of the event was executed.

Tests of this type are typically done with a mocking framework, such as RhinoMocks (the tool used in the samples). Mocking frameworks allow tests for behavior in addition to state, and since the test needs to validate that an event was raised, RhinoMocks is the perfect fit. A deep dive into mocking and behavior testing is beyond the scope of this book. Look at the code, digest it, and tinker with it. It's a great way to expand your testing knowledge!

Mocking frameworks create proxy objects based on interfaces. For the single event, create an interface (shown in Listing 4-16) that has the required signature for the event handler — in this case, the PropertyChanged event.

public interface IPropertyChangedSubscriber
{
    void Handler(object sender, PropertyChangedEventArgs e);
}

The test starts off by creating a mock of the subscriber and registering the PropertyChanged event with the handler. The test acts on the Customer object by changing the name and then asserts that the handler was called. The Arg<object>.Is.Anything syntax tells RhinoMocks to not test the arguments for equality. Again, the test is just verifying that the event is raised when a property on the Customer object is updated. See the code in Listing 4-17.

[Test]
public void Should_Raise_Property_Changed_Event_On_Property_
   Change()
{
    var sut = new Customer();
    var eventArgs = new PropertyChangedEventArgs(string.
   Empty);
    var subscriber = MockRepository.GenerateMock<IPropertyCha
   ngedSubscriber>();
    sut.PropertyChanged += subscriber.Handler;
    sut.Name = "New Name";
    subscriber.AssertWasCalled(x => x.Handler(Arg<object>.
    Is.Anything, Arg<PropertyChangedEventArgs>.Is.Anything));
}

The repository pattern is commonly used for Line of Business applications to move data between the data store and the model classes. For the sample ViewModel, I've included a very simple interface (shown in Listing 4-18) that has a GetAll method and an Update method (not even remotely a complete repository, but all that we need for the examples). Note the use of generics to enforce strong typing in the repositories that implement this interface.

public interface IRepository<T>
{
    IList<T> GetAll();
    bool Update(T model);
}

The repositories in the samples return hard-coded values instead of connecting to a data store. It's common practice to create classes that are used only for testing or prototyping. The convention I prefer is to call them out by appending Fake to the name (as shown in Listing 4-19) so other developers have no doubt about their intended purpose. Additionally, the examples don't implement the Update methods because they aren't used for the ViewModel samples shown.

public class SalesRegionRepositoryFake :
   IRepository<SalesRegion>
{

   public IList<SalesRegion> GetAll()
   {
       var list = new ObservableCollection<SalesRegion>
       {
           new SalesRegion {ID = 1, Name = "East"},
           new SalesRegion {ID = 2, Name = "Central"},
           new SalesRegion {ID = 3, Name = "West"}
       };
       return list;
   }

   public bool Update(SalesRegion region)
   {
       throw new NotImplementedException();
   }
}

To create a customer, a list of Sales Regions must be available, so the Customer Repository Fake (as shown in Listing 4-20) uses Constructor Injection to insert the allowable values into the repository. It could have created its own list, but that would have thrown off the binding in XAML since the objects would be different.

public class CustomerRepositoryFake : IRepository<Customer>
{
    readonly IList<SalesRegion> _salesRegions;

    public CustomerRepositoryFake(IList<SalesRegion>
   salesRegions)
    {
       _salesRegions = salesRegions;
    }

public IList<Customer> GetAll()
    {
        var list = new ObservableCollection<Customer>();
        var customer = new Customer {Name = "Jane Doe", ID=1,
   SalesRegion = _salesRegions[0]};
        list.Add(customer);
        customer = new Customer {Name = "John Smith", ID=2,
   SalesRegion = _salesRegions[1]};
        list.Add(customer);
        customer = new Customer { Name = "John Doe", ID = 3,
   SalesRegion = _salesRegions[2] };
        list.Add(customer);
        return list;
    }
    public bool Update(Customer customer)
    {
        throw new NotImplementedException();
    }
}

Interestingly enough, using the ViewModel pattern, the commands can be developed prior to the view, enabling Test Driven Development for the commands. Using the same approach discussed in the "Commanding Attention" section earlier in this chapter, a CommandBase class (shown in Listing 4-21) is extracted to hold the common properties and the CanExecuteChanged event.

public abstract class CommandBase : ICommand
{
    public string Text { get; internal set; }
    public abstract void Execute(object parameter);
    public abstract bool CanExecute(object parameter);
    public event EventHandler CanExecuteChanged
    {
        add { CommandManager.RequerySuggested += value; }
        remove { CommandManager.RequerySuggested -= value; }
    }
}

The AddCustomerCommand (shown in Listing 4-22) will take the Customer list as a parameter and add another customer to the list. In this example, it's a hard-coded set of values, but in reality you would probably have another Window (or some data entry mechanism) to gather the required information.

The CanExecute event handler checks that the parameter is a List<Customer>. There is an additional check in the Execute method. It is essentially redundant — the command should never execute if the parameter is not an IList<Customer>. However, defensive programming kicks in, and I always check again to avoid the possibility of throwing an error.

public class AddCustomerCommand : CommandBase
{
    public AddCustomerCommand()
    {
        Text = "Add Customer";
    }
    public override void Execute(object parameter)
    {
        var list = parameter as IList<Customer>;
        if (list == null)
        {
            return;
        }
        list.Add(new Customer { ID = 4, Name = "New Customer" });
    }
    public override bool CanExecute(object parameter)
    {
        return parameter is IList<Customer>;
    }
}

[Test]
public void Should_Not_Execute_If_Parameter_Is_Null()
{
    var cmd = new AddCustomerCommand();
    var canExecute = cmd.CanExecute(null);
    Assert.IsFalse(canExecute);
}
[Test]
public void Should_Not_Execute_If_Parameter_Is_Not_List_
   Customer()
{
    var cmd = new AddCustomerCommand();
    var canExecute = cmd.CanExecute("test");
    Assert.IsFalse(canExecute);
}
[Test]
public void Should_Execute_If_Parameter_Is_List_Customer()
{
    var cmd = new AddCustomerCommand();
    var canExecute = cmd.CanExecute(new List<Customer>());
    Assert.IsTrue(canExecute);
}

[Test]
public void Should_Add_Customer_To_List_On_Execute()
{
    var cmd = new AddCustomerCommand();
    var customers = new List<Customer>();
    var count = customers.Count;
    cmd.Execute(customers);
    Assert.AreEqual(count+1, customers.Count);

}

So, you're thinking to yourself at this point, "There's been a lot of code slung so far. And we haven't even touched the ViewModel yet?" And you're right. However, as you will soon see, the ViewModel becomes a rather trivial exercise because of the setup that we have already done. There are just three properties in the ViewModel and two lines of code that need to be run in the constructor (and one of them is required by the XAML rendering engine). Yep. That's it.

The image in Figure 4-6 contains two combo boxes that need to be populated. One of the tenants of the ViewModel pattern is to provide a one-stop shop for the View. In addition to the main data (Customers), this includes any reference data (Sales Regions). The ViewModel (shown in Listing 4-24) contains these IList<T> as properties that can be bound to in the view and (in this example) are populated in the constructor.

The Window also contains a single Button that needs to be bound to the AddCustomerCommand. Commands require a bit more plumbing, because they must be instantiated prior to use. The technique shown in this sample is just in time instantiation and is meant to cut down on resource consumption. If the button never gets clicked, why create the command in memory?

public class CustomerMaintenanceViewModel
{
    ICommand _addCustomerCmd;

    public CustomerMaintenanceViewModel()
    {
        Regions = new SalesRegionRepositoryFake().GetAll();
        Customers = new CustomerRepositoryFake(Regions).
   GetAll();
    }
    public IList<Customer> Customers { get; set;}
    public IList<SalesRegion> Regions { get; set;}

    public ICommand AddCustomerCmd
    {
        get { return _addCustomerCmd ?? (_addCustomerCmd =
   new AddCustomerCommand()); }
        set { _addCustomerCmd = value; }
    }

}

There are a couple of items worth mentioning when it comes to the view. First and foremost, the constructor for the view needs to assign its DataContext to an instance of the ViewModel (see the bolded line in Listing 4-25).

public partial class CustomerMaintenance : Window
{
    pubblic CustomerMaintenance()
    {
        InitializeComponent();
        DataContext = new CustomerMaintenanceViewModel();
    }
}

Wait! Didn't I say we want to remove all code from the code-behind? No, not all code. Almost all code. Event handlers stuffed with business logic, definitely. But you have to have two lines in the constructor: InitializeComponent(), which renders all the XAML, and the DataContext assignment. You might have cases for additional code living in the code-behind, and those cases might be perfectly valid. Just use critical thought before you start adding code in places where it can't be tested or reused.

The Command Binding expressions become very different using the ViewModel pattern. They actually become quite a bit easier as shown in Listing 4-26. Since the base class hooks the Command into the CommandManager, the need for the Windows.CommandBindings section is eliminated.

<Button HorizontalAlignment="Right" Margin="3,0,3,0"
   Command="{Binding Path=AddCustomerCmd}"
   CommandParameter="{Binding Path=Customers}"
Content="{Binding RelativeSource={RelativeSource
   Mode=Self},Path=Command.Text}"
/>

The Content hasn't changed from the earlier examples, but the Command and CommandParameter assignments have. The DataContext for all controls roll up the element tree looking for the first DataContext. Because the only DataContext is set at the Window level (in the constructor), all elements have as their DataContext the ViewModel. So binding is reduced to setting the Path to the property of the ViewModel (in this case, the AddCustomerCmd for the Command, and the Customers property for the Command Parameter).

Likewise, ComboBoxes bind their ItemsSource property to the IList<T> properties in the ViewModel. Listing 4-27 shows the XAML for the two ComboBoxes on the Window.

<ComboBox ItemsSource="{Binding Path=Customers}"
   DisplayMemberPath="Name"/>
<ComboBox ItemsSource="{Binding Path=Regions}"
   DisplayMemberPath="Name"
   SelectedItem="{Binding ElementName=CustomerList,Path=Selec
   tedItem.SalesRegion}"
/>

The second ComboBox shows the power of WPF data binding. The SelectedItem should be set to the value of the SalesRegion property for the Customer. To do this through binding, the item is set to the SelectedItem of the CustomerList. This returns a Customer object, allowing any property on that Customer to be selected in the Path (in this case, the SalesRegion property).

I was asked recently if using the ViewModel pattern is worth it since it "seems like a lot of extra work." This is a common theme among WPF developers currently, and it isn't surprising considering the newness of the pattern, all the current variations in the wild, and conflicting opinions on the subject.

In short, it is absolutely worth it. The biggest benefit the ViewModel brings to the table is true separation of concerns with a side of testability. Any time you can reduce the dependence on manual user testing and increase automatic test coverage, it's a win. Increased code isolation, improved capabilities for code reuse, and reduced complexities all come with the package. And there isn't "more" code developed — it's just moved out of the code-behind files for the Windows.