tags:

views:

1204

answers:

2

I understand that in MVVM:

  • the View knows about the ViewModel
  • the ViewModel knows about the Model
  • but it doesn't work upwards, so the Model knows nothing about the ViewModel
  • and the ViewModel knows nothing about the View

So how does the ViewModel respond to actions that the user does on the View, e.g. type something into a TextBox or move a slider, etc.

  1. I understand that this is done with RoutedEvents but almost all RoutedEvent examples I find use CodeBehind in the View, which is exactly what you don't have anymore in MVVM.

  2. So that leaves RoutedCommands which I find more examples of in MVVM but e.g. moving a slider really isn't a command in that sense, it is an event, so I am wondering if this is really what should be used.

  3. Then I read advice such as "In MVVM use RoutedEvents as little as possible, and no RoutedCommands at all." OK.

  4. So that leaves, e.g. in the WPF Model-View-ViewModel Toolkit 0.1 project form the WPF team themselves you have a "DelegateCommand" which also looks like an interesting way.

  5. Then some people are also using "RelayCommand".

This is a lot of choices and confusion for doing something so core to developing applications.

What is the best way to simply do in MVVM what we were doing for the last 10 years with Code Behind:

  • create button
  • double-click button
  • write handling code
+3  A: 

For buttons and other triggers I use the ICommand interface supplied by WPF in a similar fashion to the DelegateCommand that you linked to. (actually I use a Relay Command as defined here)

When you are changing a value (moving a slider, typing into a text box) use bindings and handle behaviour when the property in the ViewModel is set.

Generally I find that there is very little reason to use RoutedEvents in a MVVM application, but they are a nice, familiar comfort blanket when you can't achieve what you want to through the new WPF specific methods.

Martin Harris
+6  A: 

Just to be clear, when people mention DelegateCommand and RelayCommand, they are really talking about the same thing: an implementation of ICommand that allows you to pass in a delegate. You can use them interchangeably.

As far as I am concerned, having your view (XAML) bind to DelegateCommands in the ViewModel is the best way to implement MVVM.

I stay away from RoutedEvents AND code-behind whenever possible.

Brian Genisio
This is enlightening, thanks. The first thing books on WPF tell you is how much better RoutedEvents and RoutedCommands are than the old way in WinForms (they can tunnel down and bubble up the tree, etc.) so I assumed this was how everything was done in MVVM. Interesting to know that even though RoutedEvents and RoutedCommands are so new and improved, they still aren't useful for writing decoupled applications.
Edward Tanguay
Thats right, in my opinion. The MVVM pattern is becoming so popular because RoutedEvents and RoutedCommands (and other UI features) are so damn heavy. If you want to write decoupled, testable classes that encapsulate your view logic, you need to decouple them from the view. MVVM really shines with this, just as long as you look at what the WPF and Silverlight books say as an outdated view of developing in this environment.
Brian Genisio