Where should I set the DataContext - code behind or xaml?

(honestly I searched and read all the 'related questions' that seemed relevant - i do hope i didn't "miss" this question from elsewhere but here goes...)

There are two different ways (at least) to set the DataContext. One can use XAML or one can use the code behind.

What is the 'best practice' and why?

I tend to favor setting it in XAML because it allows a desig开发者_StackOverflow中文版ner to define collections on their own but I need 'ammunition' on why it's a best practice or why I'm crazy and the code behind is the bomb...

A third way you might look at is using a locator service. I usually have one class that is responsible for the creation of all my DataContext(VM's in most cases for me) and I create an instance of that class in the App.xaml Resources. Then I bind the DataContext in the XAML of each individual page.

i.e.

<Page DataContext="{Binding ViewModel,Source={StaticResource Locator}}" >

I think it depends on what you are setting the DataContext to, and ultimately personal preference.

I personally always do it in the code behind of my views because I find it overall cleaner, and it was how I was taught MVVM. Another thing to keep in mind is, there are times you may need to change your datacontext depending on what you are working with. If this is the case it's much cleaner/easier to do in the code behind rather than in XAML.

As you can see by the answers so far opinion is divided. In truth there is no best practice (I do get bee in my bonet about discusions of "best practice" in the Silverlight world, its way too young for best practice to be truely known.)

The reality actually is that you can't set the "data context" in Xaml. Unless you actually construct an object instance like this:-

<UserControl>
  <UserControl.DataContext>
    <local:MyDataProviderThing />

Ultimately something external has to assign either the DataContext property directly or indirectly via another property or via binding (as in Stephan's answer). Its this external context which is dictates whether it makes sense to do it in Xaml or not. Many MVVM solutions use a binding in Xaml, in some cases simply to avoid there having to be any code at all in code-behind rather than it truely being "better". Others set up the DataContext in code using a base class that your control derives from.

DataContext of the user control/view I assume? One advantage of setting data context in the code behind is the availability of dependency injection. Your DI container can take care of any dependencies for you dynamically at run-time.

With this pattern, I frequently set a view's Blend design DataContext in xaml using d:DataContext. The "design version" can provide mock data for use in Blend, while the true implementation is resolved at run-time.