行走视觉树不好的做法？

Question

最近我见过一些关于行走视觉树是不好的练习（here for instance）的评论，但我还没有看到或找到一个为什么这是不好的练习的原因。

在一个项目中我的工作有相当多的树遍历，所以我不知道我是否应该去改变这一切别的东西，还是让它是因为它是。

所以，我猜这里我主要的问题是如果视觉树行走真的是不好的做法，更重要的是，如果是这样，为什么？

而且，当（如果有的话？）会是好走可视化树？

Answer 1

1. 走视觉树往往达闯入通过WPF“自然”机制提供的抽象，手动执行什么样的框架应该由自己做（通过XAML声明，绑定等）。这只是一个黑客，简单地说。有时候表示一个人不确定如何正确使用WPF。 （顺便说一下，这确实很难使用）。

2. 你真的无法知道在任何时候都可视化树是否完整与否; WPF可能尚未生成所有控件（例如，在填充许多项目的列表时）。为了解决这个问题，你需要实施安全措施，处理LayoutUpdated事件等，这使你的代码过于复杂。

Answer 2

我会先说你会对这个问题有各种各样的意见。

在你链接的例子中，我会说在这种情况下的可视化树步行者是错误的解决方案 - WPF通常最适用于某种MVVM或类似MVP的模式，这意味着数据绑定，并且如果你绑定到适当的结构，你可以消除很多你可能已经做的视觉树行走。

我只倾向于使用它的“特殊效果”，因为它是。我工作的大型WPF内部应用程序有一些视觉树行走代码，它以一种可重复使用的方式为一些ItemControl添加了一些便捷行为（使用类型参数使这一行为有很多乐趣）。

我们也走可视化树中的一些附加属性，它们控制特定用户是否被允许来操作UI的某些部分系统的一部分的实施。这是因为这个系统必须转换视觉树，而不管底层数据是什么 - 用户权限是一个贯穿始终的问题，底层数据在每一步都不必担心。

基本上我们只做它做的事情的UI本身 - 用户界面的行为，不能以更方便的方式完成（老实说，大多数情况下，大多数其他方式更方便），或实际上调整可视化树基于一些在用户界面绑定的数据中不便于表达的因素。如果是关于操纵数据，我们总是在后端数据结构或ViewModels中执行。

Answer 3

这取决于你为什么走路视觉树。有很多机制可以使您的视图自动化，并且在大多数情况下，它们甚至足以完成非常复杂的控制。

在我多年与WPF我已经使用可视化树创造了无法以其他方式做了一些非标准的行为走的时候只工作（或我没有找到其他的方法来做到这些）。我认为走可视化树就像其他任何反射工具一样。这是很好的了解它，它有它的应用和缺点。