是因为控件程序员太懒、太难实现还是知识不够？
无论是来自第 3 方供应商的自定义控件还是 Microsoft 本身，很多控件通常具有 clr 属性而不是 DP。结果是我无法绑定(bind)到它们，wpf 不就是绑定(bind)吗？ :/
我的下一个问题是，为什么这么多 wpf 控件提供可视部分，但它们不是可视树的成员？请参阅 wpf 数据网格列、标题...
你觉得怎么样？
最佳答案
您没有提供您正在考虑的控件的示例，即使这样也很难了解设计和实现这些控件的人员的动机，但这里有一些想法:
- 某些 WPF 和 Silverlight 控制套件是从已建立的 Windows 窗体套件移植而来的。在这些情况下，设计人员通常会执行最小的移植，因此最终会得到与他们移植的 WinForms 代码相同的过程性、面向非绑定(bind)的编程模型。我记得像这样评估 Silverlight 图表套件 - 主要示例看起来与 WinForms 代码一模一样，而不是可见的绑定(bind)。
- 数量惊人的 WPF 程序员似乎并没有“理解”WPF“全部都是关于绑定(bind)”(以及样式和模板；通常，WPF 是声明性的而不是命令性的)。看看 Stack Overflow 上有多少问题询问如何在 WPF 中强制执行操作，而惯用的解决方案是声明式执行操作。
- 有时，设计者可能认为将特定属性作为绑定(bind)目标根本没有用或不合适，例如因为控件需要使用该属性执行神奇的内部操作，或者因为设计者无法设想任何场景其中属性需要进行数据绑定(bind)。
- 有时 DP 习惯用法与 CLR 属性习惯用法相矛盾。例如，CLR 集合属性通常是只读的(并且通过 Add、Remove 和 Clear 方法进行操作)——FxCop 甚至对此有一个规则。但为了可绑定(bind)，集合 DP 必须是读写的。在这种情况下，控件设计者(尤其是对 FxCop 过于信任的设计者)可能会发现自己在用 CLR 惯用法进行思考，尤其是当他们无法想到绑定(bind)场景时(“为什么有人需要绑定(bind) GridView.列集合？”)。
但这都是猜测和笼统:如果您想要一个明确的答案，您确实需要选择具体的示例并在这些控件的支持论坛上询问。
关于wpf - 为什么这么多 wpf 控件实现 CLR 属性而不是依赖属性？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2572101/