WPF数据绑定路径在内部是否被标准化?

3

我想知道在数据绑定中,是否重复使用子路径与只绑定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/>

我知道两种方法都绑定了相同的属性,但我对背后真正发生的事情很感兴趣,因为这可能会影响性能,在有多个绑定的情况下更加明显。使用绝对路径的变量是否会导致更多的“事件流量”,因为每个文本绑定都观察ViewModel属性及其特定属性? 还是完全相同?我可以想象一些BindingManager解析所有绑定路径,使得两种变体最终在IL中完全相同。
如果绑定层次结构的结构确实有影响: 除代码风格偏好之外,使用每个绑定中的完整路径的“较慢”方法是否有任何积极效果?
2个回答

2
一旦绑定对象被实例化,创建它的标记有多么复杂都不重要了;该对象包含对源属性的引用,如何找到该引用已经不再相关。因此,两种方式的性能影响只会在绑定本身被实例化时产生。
不仅不重复自己会表现得更好(几乎不可察觉),而且这是正确的做法。DRY原则与任何其他软件开发一样,同样适用于XAML。

谢谢Robert,这正好回答了我的问题。 - Simon D.

1

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

  • 绑定的目标最终必须考虑使用任一方法沿路径发生的所有属性更改事件
  • 绑定路径评估只是更大的绑定子系统的一部分

这可能类似于在像C#这样的编程语言中重新评估属性路径之间的差异。使用临时变量可能有助于性能,也可能没有。

因此,我建议以可读性和可维护性为目标组织XAML和C#,而不是性能,至少在这方面是如此。如果您必须经常重复基本数据上下文,则会发现其很繁琐,并且会使XAML看起来杂乱无章。这是通过新数据上下文间接使用属性的良好情况。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接