tags:

views:

166

answers:

3

I understand that in the MVVM pattern, that a ViewModel should know nothing about the View.

So there seems to be two ways that the ViewModel can cause something particular to happen on the UI, consider this common flow of events:

  • user types something in a textbox
  • user clicks button
  • button calls DelegateCommand called "Save" on viewmodel
  • view model saves text from textbox
  • if everything goes well during the save, the view model changes its INotifyPropertyChanged property called SaveStatus to "Succeeded"

Now in the View, I have two ways to allow this change to have an effect on the UI:

  • in the View there could be a Textblock that has a Converter on it that converts the text of SaveStatus to a phrase such as "The save succeeded."
  • in the View there could be a Trigger that checks to see if SaveStatus = "Succeeded" and if so, then a series of Setters change the UI appropriately (hiding elements, changing texts, changing colors, etc.)

Is this the basic flow of information from ModelView to View that you use in your applications?

A: 

We are using the model view controller pattern, so it goes like this:

  • user types something in a textbox
  • user clicks save button
  • the view tells the controller to save the data
  • the controller tells the view to fetch the data
  • the controller saves the data to the model
  • the controller signalizes the view that the save succeeded
  • the view shows "The save has succeeded"

I think you could use pretty much the same approach (the only difference would be that controller and model would be both the view model in your example)

bernhardrusch
+1  A: 

You can also create custom events on the viewmodel and have the view subscribe to them and react accordingly. You shouldn't need to do this very often, but it makes more sense than inspecting every INotifyPropertyChanged event for particular property names.

Ben Reierson
A: 

Is this the basic flow of information from ModelView to View that you use in your applications?

Yes. We use INotifyPropertyChanged almost exclusively for changes from the ViewModel to the view. Where the interaction is a bit more complex we use other events that the View hooks up to.

Instead of a SaveStatus message property we have a HasChanges boolean on an EditableAdapter, which wraps our POCO and provides commit/rollback of changes, as well as other calculated properties. Then we can bind our Views to this HasChanges so that, for example, we can display the documents name with a * on the end to show it has changes, or use the HasChanges to disable/enable a Save button.

Cameron MacFarland