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, e.g.

• AttachedBehaviors I get from here
• DelegateCommands I get from here

Now I'm looking for some way to handle the ItemSelected event in a ComboBox and am getting suggestions of tricks and workarounds to do this (using a XAML trigger or have other elements bound to the selected item, etc.). Ok, I can go down this road, but it seems to be reinventing the wheel. It would be nice to just have an ItemSelected command that I can handle in my ViewModel.

Am I missing some set of standard tools or is everyone doing MVVM with WPF basically building and putting together their own collection of tools just so they can do the simplest plumbing tasks with events and commands, things that take only a couple lines in code-behind with a Click="eventHandler"?

Answer 1

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

Answer 2

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

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!