Question

我只是想知道它是否有任何区别，如果我在每个绑定中重复某个属性的子路径，或者我绑定DataContext并仅说明绑定中的相对路径。

示例：

绝对路径：

<UserControl x:Name="uc"/>
  <StackPanel>
    <TextBox Text="{Binding ViewModel.Prop1, ElementName=uc}" />
    <TextBox Text="{Binding ViewModel.Prop2, ElementName=uc}" />
  </StackPanel>
</UserControl/>

相对路径：

<UserControl x:Name="uc"/>
  <StackPanel DataContext="{Binding ViewModel, ElementName=uc}">
    <TextBox Text="{Binding Prop1}" />
    <TextBox Text="{Binding Prop2}" />
  </StackPanel>
</UserControl/>

我知道两者都绑定相同的属性，但我对幕后真正发生的事情很感兴趣，因为这可能会影响性能超过2个绑定的情况。具有绝对路径的变体是否会导致更多“事件流量”，因为每个文本绑定都会观察到ViewModel属性及其特定属性？或者它会完全一样吗？我可以想象一些BindingManager解析所有绑定路径，s .th。两种变体最终都是完全相同的IL。

如果绑定层次结构确实有影响：在每个绑定中使用“慢”方法和完整路径是否有任何积极影响（除了代码样式首选项）？

Answer 1

一旦绑定对象被实例化，创建它的标记是多么精细并不重要;该对象包含对source属性的引用，以及找到该引用的方式不再相关。因此，以一种方式对另一种方式执行的唯一性能影响将是绑定本身被实例化时。

不仅不会重复自己去（不知不觉）更好地执行，这是正确的方法。 DRY principle与XAML一样适用于任何其他类型的软件开发。

Answer 2

这两种方法之间存在一些差异，但我能想到的两个因素会减少它们之间的差异：

绑定的目标必须最终使用任一方法
绑定路径评估只是更大的绑定子系统的一部分

这可能类似于在C＃等编程语言中重新评估属性路径之间的差异。使用临时变量可能有助于提高性能，但可能没有。

因此，我建议组织XAML和C＃，其目标是可读性和可维护性，而不是性能，至少在这方面。如果你不得不经常这样做，你会发现重复基础数据上下文是乏味的，它会使XAML看起来混乱。通过新的数据上下文间接使用属性是一种很好的情况。

WPF绑定路径是否在引擎盖下正常化？

2 个答案: