What are your strategies of binding the DataContext in MVVM?

Question

These two 1-hour videos show step-by-step how to use the MVVM pattern to build simple quiz applications in both Silverlight and WPF:

Implementing Model-View-ViewModel in Silverlight

Implementing Model-View-ViewModel in WPF

What amazes me about these is how different they are structurally, for instance, how they use DataBinding:

In the Silverlight approach, we set the DataContext of a View to an ObservableCollection in the ViewModel:

<views:QuestionView x:Name="QuestionDataView" />

QuestionViewModel qdata = new QuestionViewModel();
qdata.FetchQuestions();
QuestionDataView.DataContext = qdata.Questions;

In the WPF approach, we set the DataContext of the Window to the ViewModel itself.

<view:QuizView Margin="4" />

base.DataContext = new QuizViewModel(Quiz.Create());

It just seems that every MVVM example I look at does DataContext binding in a slightly new variation and I'm trying to nail down some solid ground as to "how DataContext binding is done in the MVVM pattern".

What goes through your head when you decide to bind the DataContext to something: why bind the DataContext of a Window / View / ListBox / etc. to a ObservableCollection / ModelView / etc.? What are the advantages, disadvantages, strategies here?

Any input appreciated.

Suber

The "Implementing Model-View-ViewModel in Silverlight" video is terrible. Tim Heuer creates a repository and calls it a ViewModel. The WPF video by Josh Smith is much better. He actually knows what he is talking about. – Millburn

Answer 1

Did they mention why the different approach was used for Silverlight? It may just be a limitation of the platform.

The recommended approach is to absolutely use the view model itself as your view's DataContext. In fact, rather than creating the view explicitly, you should be creating the view model and have WPF resolve the view for you. To do so, register a DataTemplate:

<DataTemplate DataType="{x:Type local:MyViewModel}">
    <local:MyView/>
</DataTemplate>

Then you just stick your view model instance into a ContentControl, ItemsControl or whatever and WPF will render it with the appropriate DataTemplate. That DataTemplate will have the view model as its DataContext, by virtue of WPF's templating system.

Kimmie

yet another variation, nice, when you say "you should" do you mean there is an MVVM guidance somewhere? I would think that the binding should actually go in the code so that it could be swapped out later e.g. at runtime, otherwise your view is tightly coupled (in XAML) to your ViewModel, right? – Suber

That particular data template is tightly-coupled yes, but sets of data templates can be swapped in and out of WPFs resource system so it becomes a moot point. – Kimmie

Answer 2

If you read the comments for the Silverlight video you'll see that the binding to an ObservableCollection was a mistake. It causes an exception to be thrown.

Most of the time the View is bound to the ViewModel (I can't in fact think of a reason when I wouldn't do that)

Kents example above is the general rule I follow, getting Silverlight to create the view for me given a collection of ViewModels.

Municipalize

thanks for pointing that out, to quote the comment: "The rule of thumb is that DataContext should be set to the ViewModel, and that all data elements should be obtained through properties of this object." Makes sense. – Suber

yes I would think the View should be bound to the ViewModel, but in the WPF example he binds the WINDOW which CONTAINS the View to the ViewModel and somehow uses the same syntax "Binding Path=QuizName" to access the properties, so does it not matter where on teh visual tree the Datacontext is bound? – Suber

It goes up the chain and stop the moment it finds a data context. – Municipalize

Answer 3

I've had some support from some exceptionally gifted MS engineers on our project and they are binding the View datacontext directly to the the View Model.

Ideally, you should not have any code behind code other than your your data context setting - infact this can be done in XAML too.

Waltz