Why are RelayCommand or DelegateCommand not part of WPF? [closed]

Question

The Model-View-ViewModel (MVVM) approach seem to be the front-runner pattern in WPF UI development. Almost every article I read implies that it is the best-practice. Usage of RelayCommand or DelegateCommand is also prominent in many articles and it seems like it is almost impossible to implement MVVM without using either of them (or any other variations). So why aren't they part of .NET 4?

I know that RelayCommand is really simple to implement and a lot of third party toolkits already have it but I'm just wondering why Microsoft would leave out something so basic and fundamental to the implementation of a so-called "best practice"?

Plover

Answer 1

Because Microsoft takes care of WPF, and not of MVVM.

If you want a full toolkit containing all components needed for a good MVVM application, I encourage you to take a look at Prism : A good tutorial here

The basic reason is that Microsoft is focusing on "mainstream" WPF functionalities (like enhancing Controls and Bindings). MVVM is, if I am right, "supervised" by the MVVM foundation.

Anion

If you mean this, then that is just a library, not a group of people that try to maintain/supervise the MVVM pattern. – Margo

Answer 2

As with most things it comes down to money. It may be a simple class, but including it in .NET requires a lot of work. A single class must be:

1. Fully tested before release. Regression tests must be implemented for future versions as well.
2. Fully documented in several languages, which must also be verified.
3. It would have to be renamed, since using RelayCommand or DelegateCommand would most likely break any WPF out there that already has these classes, as there would be naming conflicts.

Each of these requires more work than you'd expect also (i.e. #2 would have first drafts, revisions, final approval, etc).

Found a relevant link here.

Margo

Answer 3

My personal opinion on this is that RelayCommands break the intention of MVVM.

Implementing a single command for each purpose is, in my opinion, more "best practice" than using RelayCommands, as each class serves a "single-responsibility". A command should encapsulate it's behaviour in itself and not delegate it to the view model.

Debugging RelayCommands is less straight forward and a real pain when you have to step through so-and-so many more function/ actions/ delegates and jump from object to object.

Slat

I don't really see them breaking any of the promises MVVM makes. In the end MVVM is all about decoupling, eg from view and the logic behind it, and those commands achieve that perfectly. SRP is undeniably one of the most important principles, but you have to take care where you put the R.. For me the responsability of a RelayCommand is to provide a way to execute something is reponse to an event, and I like to put that 'something' in the VM itself, so the command has only a single depency (the VM). Else the command could have a dependency on one or more objects introducing tighter coupling. – Teledu

... but it all depends on the exact situation off course. I also have a lot of RelayCommands that do not depend on the VM but just publish an event to an EventAggregator or so. In that case it would be madness to forward the request to the VM. – Teledu