Generally speaking, your viewmodel should be reactive - it should react to things the user does to the XAML/view.
So when the user selects an item in combo1, that raises events and so forth. Your viewmodel should have a property that is bound to the combo1 value. So when the user changes that value, the viewmodel property is automatically set via data binding.
When the viewmodel property is set, you can clearly trigger other work - you wrote the setter after all :)
So in that setter, you'd load the data to populate combo2. And you'd set this data as the value for another property on the viewmodel.
The combo2 control would be data bound to this other property on the viewmodel. So when that property changes (because it has the new values for the list), the combo2 control automatically updates to reflect those new values via data binding.
The great thing is that the viewmodel doesn't even know it is dealing with ComboBox controls. All it knows is that it has a List1SelectedValue property. And when that property is changed, the viewmodel gets a new list of values to populate its List2Items property.
So a UI designer person could come along and replace your ComboBox controls with ListBox controls or any other list-type control and your viewmodel would continue to work just fine.
That, imo, is the power of the MVVM pattern.
The data provider model was introduced by Microsoft for WPF. I think it was a prototype of MVVM-ish thinking on their part.
It is telling that there is no data provider model in Silverlight. And that the VS10 XAML designer doesn't use the data provider model.
I believe it is a failed idea. That happens.
And I can see why. When we build the CSLA data provider concept in Silverlight we sort of mirrored the WPF idea - but with major differences. Why? Because the WPF approach is really hard to work with in some important ways (commanding in particular).
There's really no future in the data provider model, and my focus has shifted entirely away from it in the past several months. For super-simple forms it is fine, but as soon as you have multiple interacting objects (like two combobox controls) the data provider model offers no good solution, and MVVM is a better technique.
And this is why I created the ViewModelBase and ViewModel types - because I want the basic productivity of the data provider, but with the more flexible implementation. It is basically the same effort to create a simple edit form with the data provider or viewmodel, but it is easier to use viewmodel to create more complex forms.
Copyright (c) Marimer LLC