Commands and MVVM principles - RelayCommands

Question

I'm new at C#, WPF and MVVM pattern. Sorry for this quite long post, I am trying to set all my points of understanding (or non understanding).

After studying a lot of texts on the commanding mechanism provided by WPF and the MVVM pattern, I have a few problems getting my mind straight on how to use these things.

I understand that the commands provided for WPF allows to define multiple "calling points" for command logic that is held in a component of the visual tree. When a command is called, the call bubbles through the visual tree (starting at the command target or the focused element) until it bumps into an element holding a CommandBinding that defines where is the command logic.

What seems nice about that is that you can define public commands without specifying either the logic nor the calling points at first.

I also understand that following the MVVM pattern, the ViewModel of a View should handle the logic whereas the base WPF implemtentation of commands only allows visual elements to handle it because the call bubbles through the visual tree.

I then found that custom implementations such as Josh Smith's RelayCommand can be used in this case, as you bind a command called by an element of the view (button for example) to the RelayCommand object in the underlying ViewModel.

But then, I dont see how it's a command (by the definition of WPF commanding pattern) anymore since we're directly specifying an implementation that is referenced in the ViewModel. With this method, we loose all the benefits of being able to call a command from anywhere without knowing where the logic is implemented. In this case, why not directly use a Click event handler (for example) ?

Could someone explain me where I'm wrong ? (thanks for those who read the post to the end !)

Regards. NR

Answer 1

But then, I dont see how it's a command (by the definition of WPF commanding pattern) anymore since we're directly specifying an implementation that is referenced in the ViewModel.

This is still a command, and implements ICommand, but it's no longer taking advantage of the routing strategies built into WPF. It's a command, but no longer a RoutedCommand - so in a sense, you're right - it's not following the original concepts of WPF's routed commanding infrastructure, but it's still a command.

With this method, we loose all the benefits of being able to call a command from anywhere without knowing where the logic is implemented. In this case, why not directly use a Click event handler (for example) ?

You're still keeping the benefits of having the logic separated from the View. The View doesn't need to know how this is implemented, and the ViewModel can implement the command without knowing how the View will trigger it. The command can still come from a gesture, a button, etc - and be changed (completely within the XAML), without changing the logic and code at all.

Switching back to event handlers breaks this - if you use event handlers, changing the View's implementation requires updating the event handlers (code behind).