Update 3/10/2017: Added Code Sample, plus minor fixes.
Update 9/22/2016: Note that in these code snippets, I’m inheriting ViewModelBaseClass which is where methods like SetProperty reside, and where INotifyPropertyChanged is implemented. If you are using a framework like MVVMLite or Prism, you will probably be using their base class. I’ll be covering what goes in a MVVM base class in a future post

This post was prompted by listening the excellent Coding Blocks podcast, that somewhat failed in my opinion when describing the Command Pattern.  The problem is that these 3 guys are all web guys, and their treatment of some patterns that are primarily used by desktop/client apps shows this up. The most recent podcast reflects this in the discussion of the Command Pattern (where they seem to struggle to find implementation examples), and contrasts strongly with their discussion of the Repository Pattern.

This is the bit where I now fall flat on my face trying to do a better job, but here we go.  If you are for some reason put off MVVM, WPF, UWP or any other sort of app with a XAML front end because you might have to encounter the command pattern, don’t be. While I might agree with them that a dictionary definitions might sound confusing, implementation of this pattern is not bad at all. You may find it’s already been done for you if you choose an MVVM framework such as Prism or MVVMLite.

So what’s involved?

• ICommand implementation
• Delegates for Execute and CanExecute (the methods that ICommand implements)
• Usually, Some properties to bind UI controls to.

I’ve seen books showing a full complete implementation of ICommand for every command you wish to do, but in practice, there is a better way. The problem with creating new command classes for each case is that for each button or action you might want to do you may find you need to create a new command, so if you have  a simple app with a few buttons and dialogs you will quickly finds you have a whole host of ICommand implementations.  The better way is to have one generic implementation, and pass into the constructor delegates that know about the state of the object it’s being called from. Usually this object will be your view model and may contain delegates for several instances of the ICommand implementation.

So here’s some code:

using System;
using System.Windows.Input;

namespace MVVMBase
{
  public class DelegateCommand : ICommand
  {
    //These delegates store methods to be called that contains the body of the Execute and CanExecue methods
    //for each particular instance of DelegateCommand.
    private readonly Predicate<object> _canExecute;
    private readonly Action<object> _Execute;

    //Two Constructors, for convenience and clean code - often you won't need CanExecute
    public DelegateCommand(Action<object> execute, Predicate<object> canExecute)
    {
      _canExecute = canExecute;
      _Execute = execute;
    }

    public DelegateCommand(Action<object> execute)
      : this (execute, null)
    { }

    //CanExecute and Execute come from ICommand
    public event EventHandler CanExecuteChanged;

    public bool CanExecute(object parameter)
    {
      return _canExecute == null ? true : _canExecute(parameter);
    }

    public void Execute(object parameter)
    {
      if (!CanExecute(parameter))
        return;

      _Execute(parameter);
    }

    /// <summary>
    /// Not a part of ICommand, but commonly added so you can trigger a manual refresh on the result of CanExecute.
    /// </summary>
    public void RaiseCanExecuteChanged()
    {
      CanExecuteChanged?.Invoke(this, EventArgs.Empty);
    }
  }
}

I’ve called this class DelegateCommand, though RelayCommand is also a common name for it. So now that you have this implementation of ICommand, how do we hook it up to do something. Here’s a way to do that:

public class MainScreenViewModel :  ViewModelBaseClass
  {
  public MainScreenViewModel()
  {
    //Initialize the command
    ShowMessageCommand = new DelegateCommand(ExecuteShowMessage, CanExcuteShowMessage);
  }

  //The execute and can execute methods.
  private bool CanExcuteShowMessage(object obj)
  {
    return !string.IsNullOrWhiteSpace(MyName);
  }

  private void ExecuteShowMessage(object obj)
  {
    MessageReady = true;
  }

  //The command property
  private DelegateCommand _ShowMessageCommand;
  public DelegateCommand ShowMessageCommand
  {
    get { return _ShowMessageCommand; }
    set { SetProperty(ref _ShowMessageCommand, value); }
  }

  //A couple of bindable properties. Note the RaiseCanExecuteChanged in the  first of them.
  private string _myName;
  public string MyName
  {
	get { return _myName; }
	set
	{
		SetProperty(ref _myName, value);
		ShowMessageCommand.RaiseCanExecuteChanged();
	}
  }
  private bool _messageReady;
  public bool MessageReady
  {
    get { return _messageReady; }
    set { SetProperty(ref _messageReady, value); }
  }
}

And last bit, to bind this to a button. In this case, I’m using a UWP app and compiled bindings, but the XAML is virtually the same in WPF, Windows Runtime or Silverlight XAML.

<StackPanel Margin="24,0">
      <TextBlock FontSize="24" Margin="0,24">My Simple test app</TextBlock>
      <TextBlock>Please enter your name</TextBlock>
      <TextBox Text="{Binding MyName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
      <Button Content="Press to see your message!" Command="{x:Bind ViewModel.ShowMessageCommand}" Margin="0,12" />
      <TextBlock Visibility="{x:Bind ViewModel.MessageReady, Converter={StaticResource boolToVisibility}, Mode=OneWay}" >
        <Run Text="Hello" />
        <Run Text="{x:Bind ViewModel.MyName}" />
      </TextBlock>
    </StackPanel>

Note that when we do this, the CanExecute method of the command is in control of enabling and disabling the button. so there is no need for a separate IsEnabled property to bind to.

OK, so this is a slightly contrived example. The TextBlock allows you to enter some text and when text has been entered, it allows you to click a button, which then shows a second message. It might be more reasonable if the execute took you to a second screen, or showed the message in the message box. Still, hopefully it illustrates the point and concept of commands.

It’s worth noting that there are several built in commands that you can bind to. They are found in System.Windows.Input.ApplicationCommands and can be hooked up like this:

<StackPanel>
  <Menu>
    <MenuItem Command="ApplicationCommands.Paste" />
  </Menu>
  <TextBox />
</StackPanel>

 ^{From the MSDN Commanding Overview}

As I said earlier, you might get a leg up by using a framework with built in implementations for you, such as Prism, MVVMLite, Template 10 or others. and some of these may have additional implementations, such as DelgateCommand<T> in Templat10.

If this helped, or I’m botching this up, please let me know. Also, do listen to Coding Blocks, even though I think they missed something by neglecting to mention XAML at all in their discussion of the Command Pattern, I heartily recommend their podcast as an entertaining and in-depth look at software development.

Code Sample: MVVMBase.Zip