ICommand vs RoutedCommand

Question

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?

Shrubbery

Answer 1

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:

• Using RoutedCommands with a ViewModel in WPF
• Relaying Command Logic
• Simple Command (almost identical to Relay Command but worth reading)

Revest

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. – Shrubbery

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. – Youngster

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. – Youngster

Answer 2

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.).

Communal