（老实说，我搜索并阅读了所有似乎相关的“相关问题” - 我希望我没有从其他地方“错过”这个问题，但这里是......）
有两种不同的方法（至少）来设置 DataContext。可以使用 XAML，也可以使用背后的代码。
什么是“最佳实践”，为什么？
我倾向于在 XAML 中设置它，因为它允许设计人员自己定义集合，但我需要“弹药”来说明为什么这是最佳实践或为什么我很疯狂，而背后的代码就是炸弹......
【问题讨论】：
标签： wpf silverlight datacontext
您可能会考虑的第三种方法是使用定位器服务。我通常有一个类负责创建我的所有 DataContext（在大多数情况下对我来说是 VM），并且我在 App.xaml 资源中创建了该类的一个实例。然后我在每个单独页面的 XAML 中绑定 DataContext。
即
<Page DataContext="{Binding ViewModel,Source={StaticResource Locator}}" >
【讨论】：
我认为这取决于您将 DataContext 设置为什么，以及最终的个人偏好。
我个人总是在我的视图后面的代码中这样做，因为我发现它整体上更干净，这就是我学习 MVVM 的方式。要记住的另一件事是，有时您可能需要根据正在使用的内容更改数据上下文。如果是这种情况，那么在后面的代码中而不是在 XAML 中做会更干净/更容易。
【讨论】：
从到目前为止的答案中可以看出，意见分歧很大。事实上，没有最佳实践（我确实在讨论 Silverlight 世界中的“最佳实践”，因为它太年轻，无法真正了解最佳实践。）
实际情况是您无法在 Xaml 中设置“数据上下文”。除非你真的像这样构造一个对象实例：-
<UserControl>
<UserControl.DataContext>
<local:MyDataProviderThing />
最终，外部的东西必须直接或通过另一个属性或通过绑定间接分配 DataContext 属性（如斯蒂芬的回答）。它的外部上下文决定了在 Xaml 中执行此操作是否有意义。许多 MVVM 解决方案在 Xaml 中使用绑定，在某些情况下只是为了避免代码隐藏中必须有任何代码，而不是真正“更好”。其他人使用您的控件派生的基类在代码中设置 DataContext。
【讨论】：
DataContext 属性。但正如斯蒂芬的回答所显示的那样，实际分配的只是一个Binding。这本身并不是真正的“数据上下文”。分配给“数据上下文”的实际对象是在分配给名为Locator 的静态资源的对象的ViewModel 属性中的代码中执行的。
我假设的用户控件/视图的DataContext？在后面的代码中设置数据上下文的一个优点是依赖注入的可用性。您的 DI 容器可以在运行时为您动态处理任何依赖项。
使用这种模式，我经常使用 d:DataContext 在 xaml 中设置视图的 Blend 设计 DataContext。 “设计版本”可以提供在 Blend 中使用的模拟数据，而真正的实现是在运行时解决的。
【讨论】：