Question

Right, sticking with the MVVM focus for the minute, there are a small number of scenarios where threading may occur:

As usual, for simplicity we have a Model class, ViewModel class and View class.
The Model has a Collection and a string property.

1) User triggers long running background task. View triggers ViewModel. Can easily be managed by ViewModel using, for example, BackgroundWorker

2) Thread updates Model, ViewModel notified by Model of changes.

Previously we’ve discussed using INotifyChanged to notify changes from Model to ViewModel. The DependencyProperty system appears to marshal these to the correct thread for you.

For ObservableCollections this does not work. Therefore should my model’s public face be single threaded (Don’t like, why should the Model know about threads) or would I replicate some parts of the Model (For example the Collection above) in the ViewModel to ensure that amendments are made on the correct thread?

I think I’ve sort of answered my own question. Perhaps not. My Model does know about threads, so perhaps it’s only polite to markshal them back using the IMarshalInvoker idea mooted earlier by Colin?

Some of my problem here is that I consider MVVM to be yet another MVC variant, and historically I’ve been happy to use terms like MVP, MP, MVC pretty much interchangeably because I knew what worked with the GUI technology (usually winforms) on the V end. When I say MVVM I’m specifically looking for practical advice on what works for WPF and WPF specific foibles. I hope that explains the nature of my questions and why I’m asking them.

Answer 1

I don’t think it’s a very good idea to go all-out and implement collections in your Model as ObservableCollection, as this is “polluting” your Model in a way that’s only useful to WPF.

INotifyPropertyChanged is OK because:

• There are many scenarios where having the ability to “listen in” is useful.
• It can be utilized from pretty much any .NET code, not just WPF.
• It doesn’t give you any trouble if you want to serialize your Model.

So, I suggest to not have your model know about threads. Make your ViewModel know about threads, like this:

class Model {
    List<Widget> Widgets { get; private set; }
}

class ModelViewModel {
    ObservableCollection<Widget> Widgets { get; private set; }

    ModelViewModel(Model model) {
        this.Widgets = new ObservableCollection<Widget>(model.Widgets);
    }
}

If Widget is a reference type and implements INotifyPropertyChanged (which would be about 100% of the time), this gets you most of the way:

• Changes to any widget will be made to model itself and will reflect upon bindings immediately
• Updates to the collection will reflect upon bindings immediately

There’s still the problem that updates to the collection (adding and removing items) will not be made to model directly. But that can be arranged:

ModelViewModel(Model model) {
    this.Widgets = new ObservableCollection<Widget>(model.Widgets);
    this.Widgets.CollectionChanged += this.PropagateChangesToModel;
}

void PropagateChangesToModel(object sender, NotifyCollectionChangedEventArgs e) {
    // do what the name says :)
}

Finally, you need to make ObservableCollection play well with being updated from a worker thread. This is a really common issue with WPF, and I refer you to the answer to this question for a solution: ObservableCollection and threading.