What is an acceptable template for a WPF team in MVVM?

Question

I am working on a WPF application and I understand the command template well, but I found that there are several different implementations of the command template for MVVM. There is an implementation of Josh Smith in his example WPF example, DelegateCommand from Prism and an implementation of CommandBindings .

My question is: what are the generally accepted best practices for using commands with MVVM? My application uses Prism, so the DelegateCommand is available to us.

My team's developers argue about which approach is "best." Some do not like the numerous .cs files created for each command, while others prefer everything to be connected via CommandBindings . I'm at a loss. Can anyone shed some light?

Answer 1

Two points are considered:

Commands provided by various MVVM frameworks, such as CommandSinkCommand or SimpleCommand (from Cinch), etc., work like regular ICommands. In particular, the CanExecute handler is evaluated whenever WPF considers that something has happened, which could lead to a change in the user interface. You can also manually force this through CommandManager.InvalidateRequerySuggested() .

In contrast, DelegateCommands <> Prism do not call the CanExecute handler unless you manually call RaiseCanExecuteChanged() on the command. If you want to change this so that it also runs when commands are usually requested, see Code http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338

EDIT:

Second point: MVVM framework commands usually take an object as a parameter to a command. In contrast, DelegateCommands <> Prism are more strongly typed (although you can, of course, have delegate commands if you want).

Answer 2

Well, I think there is no solution .

CommandBindings are not verifiable, which is easy and to introduce WPF class dependencies in the ViewModel, which is not very good. Therefore, I would not use them.

Both DelegateCommand and CommandSinkCommand (Josh Smith's solution) are good IMO ways. They are not completely different, and not one of them is superior to the others. Although, I noticed that the CommandSink version does not always work when command routing becomes more complicated (especially when using DataTemplates).

You can even combine them: use DelegateCommand and optionally use the JoshSmith version so you can combine the benefits of both. The only thing you need - some helper classes - is not very difficult to implement.

Much more important is a match in your application: if you decide what you want to use, you must follow this path through your entire application.