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