4-21: CommandBase Class in Visual C#

Encoding Code39 in Visual C# 4-21: CommandBase Class

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 { CommandManagerRequerySuggested += value; } remove { CommandManagerRequerySuggested -= 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

Is it better to code extra lines to prevent exceptions, or just wrap the code in a try-catch block Exceptions are expensive and generally should not be considered flow-of-control devices Just like their name, exceptions should be, well, exceptional It is better to code defensively and wrap your code in try-catch blocks to handle those pesky conditions users have such a knack for finding Why don t these samples have try-catch blocks Merely for brevity Logging and error handling are musts in any real code, but take a significant amount of space and could send the reader down a rabbit hole that would detract from the concepts of the current section

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; } listAdd(new Customer { ID = 4, Name = New Customer }); } public override bool CanExecute(object parameter) { return parameter is IList<Customer>; } }

The tests for the AddCustomerCommand are similar to the tests from the Commanding Attention section, earlier in this chapter In the code in Listing 4-23, the first three tests validate the CanExecute event handler; the last test validates the Executed event handler

[Test] public void Should_Not_Execute_If_Parameter_Is_Null() { var cmd = new AddCustomerCommand(); var canExecute = cmdCanExecute(null); AssertIsFalse(canExecute); } [Test] public void Should_Not_Execute_If_Parameter_Is_Not_List_ Customer() { var cmd = new AddCustomerCommand(); var canExecute = cmdCanExecute( test ); AssertIsFalse(canExecute); } [Test] public void Should_Execute_If_Parameter_Is_List_Customer() { var cmd = new AddCustomerCommand(); var canExecute = cmdCanExecute(new List<Customer>()); AssertIsTrue(canExecute); } [Test] public void Should_Add_Customer_To_List_On_Execute() { var cmd = new AddCustomerCommand(); var customers = new List<Customer>(); var count = customersCount; cmdExecute(customers); AssertAreEqual(count+1, customersCount); }

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