INotifyOnChange Performance Issues

Intresting article here; that profiles the performance of doing change notification varying ways. Notably the typical Lambda method of change notification is 3-20 times slower than string based notifications.

Lambdas have some value outside performance that must be weighed, but if your app is sluggish and uses a lot of bindings; something to consider.

MVVM uses for ApplicationCommands.Close

ApplicationCommands.Close is an example of a RoutedCommand (it’s actually a descendant RoutedUICommand). RoutedCommands are a special case in WPF which when executed fire a RoutedEvent which can then be handled up the in the Visual Tree. It’s a special case becase it doesn’t follow the ICommand interface; for it to work it requires Execute and CanExecute to take an extra parameter: CommandTarget.

In order to get this extra parameter it must be bound to an ICommandSource, such as a button which knowns to pass in an IInputElement into Execute and CanExecute. This makes using it in MVVM a little difficult as we would need a View element in our ViewModels.

People often think about using ApplicationCommands.Close with MVVM and Dialogs. It would be nice to bind a CompositeCommand to a Save button for example; the first command saves the second command being the ApplicationCommands.Close would trigger the dialog to close. Unfortunately there is no CompositeCommand that supports RoutedCommands and I’m not sure the concept of RoutedCommands supports the Composite Pattern (there is a possiblility here to investigate).

There are still uses for ApplicationCommands.Close in MVVM however.
If like PopUpBehaviour, your dialogs use an ApplicationCommands.Close  CommandBinding to close the Window or PopUp, binding a Close Button to ApplicationCommands.Close is an easy way to close the dialog.

In Part 2 I’ll look at how to use ApplicationCommands.Close as the signal for closing Dialogs/Windows.

EventToCommand Action – MVVM Glue

One of my favourite additions to WPF is the Blend Interactivity library which allows you to decorate behaviour into controls in XAML. This really is the glue that allows you to work around MVVM problems in third-party libraries or the framework itself.

The following is an example of a Trigger and Action, to bind SelectedItems to a ViewModel as it changes. This work around is required as SelectedItems isn’t bindable.

<ListBox Name="ItemsToChoose">
    <!-- Can't bind directly to Selected Items 😦 -->
    <i:EventTrigger EventName="SelectionChanged">
          Target="{Binding}" PropertyName="SelectedItems"
          Value="{Binding SelectedItems, ElementName=ItemsToChoose}" />

One of the most common scenarios for me is the need to execute a command when a control raises a particular event. For instance double-clicking an item in a ListView. The MVVM Light Toolkit has  a great TriggerAction called EventToCommand which has been a great help, allowing me to redirect an event and turn it into a command as such:

<ListBox Name="list">
    <i:EventTrigger EventName="MouseDoubleClick">
           Command="{Binding Path=DataContext.DoSomethingCommand,ElementName=list}"/>

There are two small short-comings with the original. Firstly that it provides no access to the EventArgs. I have tweaked the original to add an EventArgs which you can use in your bindings of the command parameter. (Source Here)

This example shows the tweaked EventToCommand, passing in the DataContext of the clicked row.

<ListBox Name="list">
    <i:EventTrigger EventName="MouseDoubleClick">
           Command="{Binding Path=DataContext.DoSomethingCommand,ElementName=list}"
 CommandParameter="{Binding EventArgs.OriginalSource.DataContext, RelativeSource={RelativeSource Self}}"/>

I have also rectified the second issue; it doesn’t implement ICommandSource so it does not handle RoutedCommands.

Requery Not Suggested

During my first WPF project I noticed (like most people starting in WPF do) that DelegateCommand.CanExecute is called once and never refreshed. To force a refresh one must call RaiseCanExecuteChanged when the state of CanExecute has changed. That had a few smells about it and was cubersome, so when I stumbled across CommandManager.RequerySuggested I thought all my problems were solved.

From MSDN ”Occurs when the CommandManager detects conditions that might change the ability of a command to execute.”

All I did was create my own DelegateCommand and proxy the CanExecutedChanged event to the CommandManager.RequerySuggested event and every time WPF noticed something change it would force a refresh of my CanExecute methods. I even had the audacticity to call it BetterDelegateCommand!!

This didn’t cause too many problems on the project, as a general rule people know to keep the CanExecute logic quick and we had linear navigation in the application so there wouldn’t have been more than 10 commands bound at anyone point.

Things quickly change when you move to apps that have multiple windows/dialogs/plugins loaded and hundreds of commands can be bound. Spice that up with a developer adding CanExecute methods that do a little more than test the value of a variable and you get a significant slowdown which is very hard to debug.

Because there are times when using the RequerySuggested method is preferable Present.Commands provides the RequeryCommandDecorator and fluent method.

MyCommand = Command.Async(new SomeAction())

For everything else there is the CanExecuteChangedDecorator and fluent command. It allows you to specify an Observable which it subscribes to, when a notification comes through the CanExecuteChanged event is fired. Using an Observable adds a powerful filtering and joing tool to define when the command ‘s state has changed.

  MyCommand = Command.Async(new SomeAction())
                                .CanExecuteChangedWhen(this.WhenPropertyChanges(x => x.SomeProperty));

Everything needs a ViewModel – CollectionViewModel

CollectionViewModelThe title is a little misleading; but everyone loves generalisations and WPF. 😉
It may have been better named view-first decomposition or something similarly benign.

One of the big issues people face when implementing MVVM is collections (example, example), primarily how do I keep my model in sync. 

The reason; IMO, is that people tend to compose their ViewModels based on the models they are trying to display on-screen. Whilst this is not a bad idea (mainly because screens tend to be modelled on the models as well 🙂 ) solutions often come from a design-first approach whereby your ViewModels represent parts of the screen (not necessarily parts of the model or only a single model).

As an example take a Customer who has a collection of Addresses. When we create ViewModels based on the Model we tend to only see our objects i.e. Customer and Address. When we see a collection the first reaction is whack in a ObservableCollection.

 When creating the view that contains a collection it will often be displayed as some type of ItemsControl. The ItemsControl will often contain buttons for Adding, Deleting, Moving etc. When we look at it from the perspective of screen decomposition it becomes much clearer that there is some list component there which needs a ViewModel.

Once we come to this realisation the CollectionViewModel becomes self-evident. It’s responsibility is to maintain the underlying model; when a ViewModel is deleted from the collection it deletes the corresponding model from the underlying collection, same for add and move. I do this by listening to CollectionChanged event and providing the collection with mapping methods between ViewModel and Model.

protected override void OnCollectionChanged(NotifyCollectionChangedEventArgs e)

  if (SyncIsDisabled)

            switch (e.Action)
                case NotifyCollectionChangedAction.Add:
  foreach (var item in e.NewItems)

                case NotifyCollectionChangedAction.Remove:
  foreach (var item in e.OldItems)

                case NotifyCollectionChangedAction.Reset:


So when decomposing screens or models into ViewModels; or when you encounter an issue with a design, double-check everything is a ViewModel.

MVVM Animation of ListBox – Present.Commands

Using the Present.Command decorator to change visual states after a command execution we can easily animate the addition and deletion of items in a WPF ListBox in an MVVM friendly way.
(The code is in svn for the async command samples)

Firstly, our ViewModel’s: we have an ItemViewModel representing an item in the ListBox; and an ItemCollectionViewModel representing our ListBox. Our ItemCollectionViewModel contains the two commands we are primarily focused on, Add and Delete.


  AddCommand = Command.Async
                       .Do(x => new ItemViewModel("New Item "))

Pretty self-explanatory, we create a new item, Add it to the collection and change the state of the new item viewmodel to “Add”


DeleteCommand = Command.Async
                    AsyncAction.FromDelegates<ItemViewModel, ItemViewModel>()
                        .Do(e =>
                                    e.Parameter.IsDeleting = true;
                                    return e.Parameter;
  .SuccessVisualState(ItemVisualStates.Delete, item => Remove(item))

The delete command is a little more involved. We set the Parameter (the item to delete) to “deleting” and sleep to simulate server call. Once we have deleted it on the server we play the delete animation (by changing the visual state to delete) and then once everything is finished we remove the item from the collection.

ListBox Item DataTemplate

          <!--Register the View, so it is acessible from Services, bind the current visual state so the ViewModel can control it-->
          <UniformGrid Name="grid" Style="{StaticResource DemoGrid}"  VerticalAlignment="Center" Commands:PresentVisualStateManager.GoToState="{Binding State}"
              <VisualStateGroup x:Name="ActionStates">
                <VisualState x:Name="Add"  Storyboard="{StaticResource AddAnimation}"/>
                <VisualState x:Name="Delete"  Storyboard="{StaticResource DeleteAnimation}"/>

            <Button Command="{Binding DataContext.DeleteCommand, ElementName=List}" CommandParameter="{Binding}" Height="20" Width="20">
                <Style TargetType="Button" BasedOn="{StaticResource ImageButton}">
                    <DataTrigger Binding="{Binding IsDeleting}" Value="True">
                      <Setter Property="Content">
                          <Viewbox Width="{TemplateBinding Button.Width}" Height="{TemplateBinding Button.Height}">
                            <Progress:CircularProgressBar />
                    <DataTrigger Binding="{Binding IsDeleting}" Value="False">
                      <Setter Property="Content">
                          <Image Source="{StaticResource imgMediumCross}"
                                 Width="{TemplateBinding Button.Width}"
                                 Height="{TemplateBinding Button.Height}" />

              <Label Content="{Binding Name}" />



Here we define the VisualStates Add and Delete and their corresponding animations (static resources)
We change the Button image to a circular progress bar whilst we are deleting.
We register the View with the ViewRegistry and bind to the delete command.
With a little more designer input we have a beautiful animating listbox 😉

Visual State Change In a Command

Using the Present VisualStateManager and the ViewRegistry we can now use a Present.Commands  decorator  to change the visual state of a ViewModel after succesful execution of the decorated command.

 The decorator has a number of overloads, the ViewModel to change state of can be passed in or returned by the do action; an action can be executed after the state transition as well.

  AddCommand = Command.Async
                   AsyncAction.FromDelegates<object, ItemViewModel>()
                            .Do(x => new ItemViewModel("New Item "))

The view has to then register itself with the registry and define a VisualState using the constant passed into the fluent method.

Putting the View in ViewModel – A ViewRegistry

One of the great things that MVVM has achieved is removing the dependency on the View in the ViewModel (Presenter). Occasionally, however,  I run into situations where I really need to know what View the ViewModel is associated with.

I need to create a dialog; which window is the owner? Or which control is the owner for pop-ups?

I want to change the Visual State with a call-back ; Which control do I pass to the VisualStateManager?

Having rejoiced that I no longer have a dependency on the View from my ViewModel, how do I get a reference to a ViewModel’s View?

The best solution I have seen thus far is the concept of a ViewRegistry. The ViewRegistry is dictionary of Views keyed by the View’s ViewModel. A View that knows it uses Dialogs or the VisualStateManager, for instance, registers itself with the ViewRegistry via an attached property. The ViewRegistry adds the View using it’s DataContext (the ViewModel) as the key. The View Registry handles the removal of unloaded views to ensure memory leaks don’t occur.

<UserControl pc:ViewRegistry.Register="true" ... >

It’s also good to note that a “View” can also be any control inside an actual view, this can be useful with things like the PopUp Dialog where you want the dialog to control a portion of a view.

  <Grid pc:ViewRegistry.Register="true" ... >

I shy away from ever injecting the ViewRegistry into a ViewModel, as this starts to bring back the coupling MVVM fought so hard to remove. Rather being viewy the ViewRegistry is used in more viewy services like the Dialog Service or Visual State Manager Service.

A View can be retrieved like this:

UIElement view = viewRegistry.FindViewFor(viewModel);

The ViewRegistry class is from Present.Core and can be viewed here.

Auto Mocking EventAggregator

A general rule about Unit Testing that I try to follow is that a change in the class under test should not break the test, unless the functionality under test is broken. It just makes things more maintainable.

For a long time, when I tested ViewModels I had a method called

StubEvent<TEvent, TPayload>()

This allowed me to stub all the required events for a test and control flow. However, when someone added a new event subscription or publication into the ViewModel,  the tests would fail as no one stubbed the new event; breaking the above rule.

The second problem when people started subscribing to Events on the UI Thread using

event.Subscribe(DoSomething, ThreadOption.UIThread);

The UIThread subscription uses Application.Current.Dispatcher which obviously isn’t there in most Unit Tests and so your subscriptions fail.

Enter AutoMockingEventAggregator; this bad boy returns a stubbed version of any event requested and adds a Dispatcher that can be used in testing. Just replace your mocked or concrete IEventAggregator with an instance of AutoMockingEventAggregator and all your testing woes are gone 😉
I even throw in a free AssertSubscriptionWasOnUiThread method.

On a separate note, if you aren’t committed/forced to use Prism’s EventAggregator, have a look at the Observable alternatives such as this one.

WPF Fluent Commands

When writing a Command in WPF there can be a number of behaviours a command may need, to fulfil it’s purpose, which are actually orthogonal to the actual responsibility of the command (let’s say saving). For example the command may need to be scheduled (in the case of Auto-Save), it may need to “busy” the View, be executed asynchronously and ensure the current user has the authorisation to save the current item. Not only that, but the delete command and the load commands may also have to do the same things!

Present‘s Fluent Commands was born to enable the reuse of these common command decorations and allow the composition of commands using a fluent api.  (recently moved to Google Code)

The inner command (Save) is wrapped in a number of decorators each which add a single extra function to the inner command. Present currently has three Command Decorators

  • Schedule Decorator – Repeatedly executes a command every given time period.
  • Requery Decorator – Commands such as Prisms DelegateCommand rely on consumers to raise the CanExecutedChanged event to force the UI to reevaluate the CanExecute value of the command. This is not always feasible. This Decorator wires the CanExecutedChanged event to the CommandManager.RequerySuggested event so the CanExecute method is regularly re-evaluated.
  • Selectable Decorator – A decorator that exposes Properties the UI can use for binding “Selectability”.

More can easily be added, for instance internally we have a security decorator and a maximum concurrent executions decorator.

Scheduled Command

The second addition is Asynchronous behaviour. The AsyncCommand and CompositeAsyncCommand take AsyncActions which describes the life cycle of the operation and are executed using a BackgroundWorker.  The composite command allows for simultaneous asynchronous execution of multiple actions as well as an action to be executed when all actions have completed. Actions can also be decorated with extra behaviour such as the BusyAsyncActionDecorator which busys the View or the ObservableAsyncActionDecorator which turns the action into an Observable.

Async Command

Fluent Commands has now been released as part of Present (recently moved to Google Code).
A sample app can be dowloaded here.