Who sets DataContext in Silverlight MVVM

Question

I have been reading about MVVM pattern from various sources like MSDN:

http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

In that article it says: Unlike the Presenter in MVP, a ViewModel does not need a reference to a view.

If the View (XAML) assumes it's DataContext is the ViewModel then where in the code is the following line:

view.DataContext = viewModel;

The ViewModel doesn't know anything about the view so it cannot set the datacontext. If I give the ViewModel the reference do I break the MVVM pattern? My other choice is to have some kind of Builder or extra Presenter whose only job is to wire the whole thing (wait for the loaded event of the View, set the DataContext).

I know different view's can share the same DataContext (e.g. set the DataContext only for the mainwindow and others will see it) but in many cases that is not possible at all nor even feasible.

Answer 1

Shawn Wildermuth has a great post about whether the View or ViewModel comes first: http://wildermuth.com/2009/05/22/Which%5Fcame%5Ffirst%5Fthe%5FView%5For%5Fthe%5FModel

I like, and use, his marriage concept where a 3rd party class creates both the view and viewmodel, and then associates the two. It's worked well for me.

Answer 2

This is a great question that has many answers. It all depends on how you want to architect your application. For instance, I use dependency injection to create my IViewModel, which in turn creates my IView and my IViewModel runs an IView.SetViewModel(this) on the constructor.

Other people may wish to use a more Blendable method by setting the DataContext in the Xaml:

<UserControl.DataContext>
    <ns:CrazyViewModel />
</UserControl.DataContext>

Sometimes the DataContext can be implied so it is set by the framework, like in the instance of a DataTemplate used by an ItemsControl. This is also pretty common in desktop WPF because it supports typed DataTemplates.

So there really isn't a wrong way to set the DataContext, just as long as what you have separates concerns, is maintainable and is also easily testable.

Answer 3

The Presenter !

Answer 4

I use MVVM a lot in with Prism. In Prism I use Unity for dependecy injection. Therefore I have an interface for every class registered with Unity including the View. The IView interface has a method like this:

void SetViewModel(object viewModel);

The ViewModel calls this method at the end of its constructor, passing itself as a parameter:

 public ViewModel(IView view, ...) 
 {  
    ...   
   this._view=view;  
   this._view.SetViewModel(this);  
 }

In the View.xaml.cs the IView interface is implemented. This will be the only code I add to the codebehind of the view:

public partial class View:UserControl, IView
{
   public View()
   {
    ...
   }

   public SetViewModel(object viewModel)
   {
     this.DataContext = viewModel;
   }

}

Answer 5

As for my own usage, the ViewModel doesn't know the View, or any interface on the View. And most of time, the View doesn't know its ViewModel, even if it is less important. The VM is just transprted by the DataContext.

This ensures that the VM and V will remain highly independant. Links are established thoughout bindings, commanding, Behaviors, Triggers & so on. Even if VM is often highly related to a given view, I try to make it as generic as possible, so that I can switch the corresponding View, and / or adapt the View behavior without needing to update the VM, except if the architectural link between V and M is impacted !

Regards,

Roland Tomczak