Why are events and commands in MVVM so unsupported by WPF / Visual Studio?

Question

When creating an WPF application with the MVVM pattern, it seems I have to gather the necessary tools myself to even begin the most rudimentary event handling,

Answer 1

According to Josh Smith's article about MVVM, it was unveiled to the world in October 2005 on John Gossman's blog.

From then I'd say it took another 2-3 years for WPF/MVVM to really take off and be accepted by the community, by then it was too late to retrofit WPF to support the issues with MVVM. Also I'd say that WPF created MVVM, so it seems backwards to have WPF change to support MVVM.

Finally, not everyone doing WPF uses MVVM, so the API needs to support the standard usage of events etc

So, to answer your question, yes everyone is currently putting their own set of tools together as the "official" support only provides the DelegateCommands framework at this time.

Answer 2

Glad to hear I am not the only one that thinks the commanding implementations out there are overkill. Databinding seems naturally well-supported but I have been banging my head for weeks trying to understand command bindings for things other than buttons and elements that inherit from it.

Thanks for posting this question. I think from now on I am going to handle all events in the view layer with a redirect to the view model functions. I think this is how they taught basic MVVM in one of Microsoft's XAMLFest 2-day course. Good enough for me!

Answer 3

Becuase MVVM was "invented" way after WPF... hence why large pieces of the MVVM puzzle are not part of the WPF framework.

Not only that but MVVM itself was declared a "pattern" before it was even proven/practised in the real world. Which is the complete opposite of what patterns are all about - they are usually spotted and documented after many years of successful use by lots of different people.

One guy coming up with an pattern does not a pattern make.

Answer 4

You're right about the complexity of commands. I try to follow the M-V-VM pattern as close as possible, but I can't justify sophisticated workarounds just to handle a simple user event.

In my opinion, it's OK to handle a user event in the View if that greatly simplifies your code. If you do handle a user event in the View, your View's code-behind should immediately call a method on the ViewModel. This way, you are still keeping your logic in the ViewModel… you just have a little plumbing code (event handler) in the View. I know the M-V-VM purists think there should be no code in the View's code-behind, but sometimes it just makes more sense to allow some simple boilerplate code like an event handler. Remember, others may have to read/modify your code in the future and it is much easier to understand an event handler than a DelegateCommand.

Answer 5

Take a look at this MVVM project template for VisualStudio.

http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx

With this template you get various DelegateCommand classes which cover different needs for ICommands, and a CommandReference class that helps with key bindings.

It's a good start...