52

Let's have a button Command property bound to a custom command.

When should I implement ICommand and when derive from RoutedCommand? I see that RoutedCommand implements ICommand.

In which case could I need to implement an ICommand? What about MVVM model? Which one suits better for this purpose?

Improve this question

2 Answers 2

Reset to default
70

As you have noticed the RoutedCommand class is an implementation of the ICommand interface, its main distinction if that its function is similar to that of a RoutedEvent:

The Execute and CanExecute methods on a RoutedCommand do not contain the application logic for the command as is the case with a typical ICommand, but rather, these methods raise events that traverse the element tree looking for an object with a CommandBinding. The event handlers attached to the CommandBinding contain the command logic.

The Execute method raises the PreviewExecuted and Executed events. The CanExecute method raises the PreviewCanExecute and CanExecute events.

In a case when you don't want the behavior of the RoutedCommand you'll be looking at your own implementation of ICommand. As for the MVVM pattern I can't say that one solution, it seems that everyone has their own methodology. However, here are a few approaches to this problem that I've come across:

Improve this answer
3
  • 1
    Thank you. I think the most important think to realize is that they traverse the tree looking for an object with CommandBinding. As in MVVM I want to avoid CommandBindings, I decide for ICommand.
    – theSpyCry
    Jul 16, 2009 at 13:37
  • Routed commands move the useful tasks from the object triggering the command, up in the visual tree, to allow sharing. In a routed command CanExecute and Execute methods only raise pairs of routed events, they do nothing else and ignore if events will eventually be handled. Usually a CommandBinding is attached to some ancestor to handle events and perform the meaningful work. In non-routed commands, CanExecute and Execute do all the work, but splitting the work using routed events allows to delocalize and share a part of the work, e.g. to manage multiple commands with a single CommandBinding.
    – mins
    Sep 19, 2019 at 15:47
  • 1
    As @PaN1C_Showt1Me already mentioned, as the routed events are a matter of view (with CommandBinding being attached to some view element), a routed command is not easy to use in MVVM, a non-routed command can be defined in the view model instead.
    – mins
    Sep 19, 2019 at 15:57
30

The only thing I would add to Rich McGuire's answer is that RoutedCommands (and their more prevalent descendant RoutedUICommand have to be wired up with event handlers to work correctly.

Most MVVM implementations I have come across attempt to leverage binding against the ViewModel and thus the ViewModel (and not the View) owns the CanExecute/Execute logic.

In contrast, the event handlers move that burden to the View. The handling can then be propagated to the ViewModel, but this means a slightly higher degree of coupling between ViewModel and View (casting + method call, etc.).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.