最近我看到一些关于走可视化树是不好的做法的评论（例如这里），但我还没有看到或找到为什么这是不好的做法的原因。
在我正在做的一个项目中，有相当多的树木行走，所以我想知道我是否应该费心将所有这些更改为其他东西，或者就让它保持原样。
所以，我想我的主要问题是视觉树行走是否真的是不好的做法，更重要的是，如果是，为什么？
另外，在哪里（如果有的话？）可以在视觉树上行走吗？
问问题
746 次
3 回答
1
遍历可视化树通常相当于打破 WPF“自然”机制提供的抽象，手动强制框架应该自己做的事情（通过 XAML 声明、数据绑定等）。简单地说，这是一个 hack。有时它表明人们不确定如何正确使用 WPF。（顺便说一句，这确实很难使用）。
您无法始终真正知道可视化树是否完整；WPF 可能尚未生成所有控件（例如，在填充包含许多项目的列表时）。为了解决这个问题，你需要实现安全措施、处理
LayoutUpdated事件等，这使得你的代码过于复杂。
于 2012-08-17T10:21:25.567 回答
1
我首先要说的是，你会在这个问题上得到各种各样的意见。
在您链接到的示例中，我会说在这种情况下可视化树步行器是错误的解决方案 - WPF 通常最好与某种 MVVM 或类似 MVP 的模式一起使用，这意味着数据绑定，如果您绑定到适当的结构，你可以消除很多你可能用视觉树行走所做的事情。
我只倾向于将它用于“特殊效果”，因为它是。我工作的大型内部 WPF 应用程序有一些可视化的树遍历代码，它以可重用的方式向几个ItemControls 添加了一些方便的行为（使用类型参数很有趣，可以使一个工作正常进行）。
我们还在一些附加属性的实现中遍历可视化树，这些附加属性是系统的一部分，用于控制是否允许特定用户操作 UI 的某些部分。这是因为无论底层数据是什么，这个系统都必须转换可视化树——用户权限是一个跨领域的问题，底层数据不应该在每一步都担心。
基本上我们只是为了对 UI 本身做一些事情——不能以更方便的方式完成的 UI 行为（老实说，大多数其他方式在大多数情况下更方便），或者实际上基于可视化树调整在 UI 绑定的数据中无法方便地表达的某些因素。如果是关于操作数据，我们总是在后端数据结构或 ViewModel 中进行。
于 2012-08-17T10:28:44.853 回答
0
这取决于你为什么要走视觉树。有很多机制可以使您的视图自动化，并且在大多数情况下，它们足以完成甚至非常复杂的控制。
在我多年使用 wpf 的工作中，我仅在创建一些无法以其他方式完成的非标准行为（或者我没有找到其他方法来完成它们）时才使用可视化树行走。我认为行走视觉树是一种与其他工具一样的工具，例如反射。很高兴知道它，它有它的应用和缺点。
于 2012-08-17T10:30:10.017 回答