views:

61

answers:

2

I'm using MVVM Light toolkit (which I love). I currently have messaging in place for some interaction originating from the ViewModel and intended for consumption by the View. Typically these types of messages indicate the View should do something like hide itself, show a confirmation message that data was saved, etc.

This works. In the constructor for the View, I register with the Messenger:

Messenger.Default.Register<NotificationMessage<PaperNotification>>(this, n => HandlePaperNotification(n));

When I'm using the Messenger to communicate cross-cutting concerns between ViewModels (like identity), I can see that when the ViewModel is cleaned up in the ViewModelLocator, the base class for ViewModels (ViewModelBase) unregisters any subscribed messages. I don't have to do anything, as MVVM Light Toolkit handles that for me. However, when I use them in the Views, I have to expressly unregister them at Closing time, like so:

Messenger.Default.Unregister(this);

I suppose I could implement a base class for Views to inherit from.

However, it strikes me that perhaps this is a code smell to be using the Messenger in the View... it works, but it might not be the best way. I'm wondering if I should instead create a property on the ViewModel and bind whatever part of the View's elements to it. In the example of hiding a form, a property could be a boolean called "Show". As I think about it, I can see that in many cases this will result in having to write a ValueConverter. One way seems less testable. The other way seems to require much more code and perhaps the introduction of excess ValueConverters, which could become a code smell in themselves.

So (after all that build up) my question is this:

Is it preferable to use messages within the View or is it better to add properties (and potentially ValueConverters) to allow the ViewModel to drive it in a more bindable fashion?

+1  A: 

In MVVM. ViewModel comunicates with View through DataBinding and Commands. If you need some other functionality, you need to implement it using this means. Messaging is supposed to be only for ViewModels. Views are supposed to be "stupid" visualisers of your data in ViewModel.

Euphoric
I think I agree, but how do you handle things like confirmation messages? If the ViewModel goes off and calls a service to save the data, then wants to forward a confirmation message that the service successfully save it... how does that mechanism work w/ wholly dumb View? Should I have a status property that is empty by default?
Mike L
What kind of confirmation? MessageBox? There is whole thread concerning MessageBoxes in MVVM.Is it some kind of text or visual representation in View? Why not use DataBinding?
Euphoric
Yup.... MessageBox. A quick search brought me several threads on using MessageBoxes in MVVM. Thanks.
Mike L
A: 

The Messaging logic in MVVM Light is there for communication between ViewModels. I've never run into any communication between View and ViewModel that I couldn't solve with binding and/or commands. Sometimes I need Value Converters and sometimes I need code in the code-behind, but I've never had to make the ViewModel directly push data to the View.

Scott Whitlock
Thanks Scott... if I could have split the answer I would have.
Mike L