1. 我会说这取决于那种用户控件的,如果是“GE neric“,你应该可以改变DataContext,因为控件在内部不应该与DataContext有任何关系。例如,如果我创建了一个ImageButton
用户控件,它公开了属性Caption
和ImageSource
,那么应该在内部独立于DataContext绑定这些属性,实例上可以绑定那些数据上下文,并且也可以更改DataContext。
<uc:ImageButton Caption="{Binding ButtonInfo.Caption}"
ImageSource="{Binding ButtonInfo.Image}"/>
在这里,人们可以再改变的DataContext简化绑定了一下:
<uc:ImageButton DataContext="{Binding ButtonInfo}"
Caption="{Binding Caption}"
ImageSource="{Binding Image}"/>
如果另一方面,用户控件是一个视图模型视图我期望的用户控件绑定到视图模型内部相对于DataContext的属性。
在一个DataTemplate在当前的DataContext已经是这一观点没有任何一个简单的实例应该做的视图模型
所以,即
<v:StatisticsView />
如果要通过视图模型是在当前的DataContext的属性,你可以绑定的DataContext还有:
<v:StatisticsView DataContext="{Binding StatisticsViewModel}"/>
2. 这可以处理任何一种方式我要说的,特别是如果你哈只有三个属性并没有太多的麻烦来创建这些属性。您可能需要考虑一些方面,如依赖性,例如将一个对象中的所有三个propeties分组是否合理?
3. 如图1指出的,这应该是从该用户控件本身显而易见的,如果它是一个StatisticsView
消费者应(通过继承当前的DataContext或通过显式绑定它或者隐含地)在StatisticsViewModel
通过。
你的用户控件做什么?行为是否依赖于虚拟机内的某些属性?消费者通常可以自由设置/绑定他们认为合适的任何属性。大多数可以调整用户控件行为的东西都暴露为属性(DP)。 – Gishu 2010-06-02 11:51:27
控制接收原始数据并对其进行消毒。 它还将抛光数据作为在UI上可见的属性进行公开。虚拟机包含将原始数据转换为抛光数据的逻辑。 – 2010-06-03 06:09:18
听起来不像UserControl行为。听起来更像是一个处理/翻译/转换器类,它接受一个数据结构并输出另一个数据结构。然后你可以通过普通的WPF数据绑定将这个新的结构绑定到UI。 – Gishu 2010-06-04 05:49:47