Question

Consider the following app architecture:

UI (View) Thread creates a ViewModel.

ViewModels constructor requests business logic object (provider) to start retrieving data from storage.

It does it by subscribing to DataRecieved event of the provider and calls the StartRetrievingData() method.

Provider creates a background thread in the StartRetrievingData() method body, loops through the obtained data and in the loop body raises DataRecieved event, passing actual data object as a custom EventArgs public field.

A ViewModel method, that is linked to a DataRecieved event then updates the observableCollection, that UI element is bound to.

Questions are:

Is everything ok with such architecture as MVVM implemntation?

At what point should I do the thread synchronization, that is calling Deployment.Current.Dispatcher to dispatch the call originated from a background thread to update the UI?

Answer 1

I would, personally, handle all synchronization requirements in your ViewModel.

If the View is constructing the ViewModel, the TPL provides a nice mechanism for this:

TaskFactory uiFactory;

public YourViewModel()
{
     // Since the View handles the construction here, you'll get the proper sync. context
     uiFactory = new TaskFactory(TaskScheduler.FromCurrentSynchronizationContext());
}

// In your data received event:
private items_DataReceived(object sender, EventArgs e)
{
    uiFactory.StartNew( () =>
    {
        // update ObservableCollection here... this will happen on the UI thread
    });
}

The nice thing with this approach is that you don’t have to pull in the WPF related types (such as Dispatcher) into your ViewModel layer, and it works very cleanly.