为什么这么多 wpf 控件实现 CLR 属性而不是依赖属性？

Question

是不是因为控件程序员太懒、太难实现或者知识不够？

无论它们是来自 3rd 方供应商还是 Microsoft 本身的自定义控件，很多控件通常具有 clr 属性而不是 DP。结果是我无法绑定到它们，wpf 不就是绑定吗？ ：/

我的下一个问题是，为什么这么多 wpf 控件提供可视化部分但它们不是可视化树的成员？查看 wpf 数据网格列、标题...

你怎么看？

Answer 1

您没有提供您正在考虑的控件的示例，即使这样也很难窥探设计和实施它们的人的动机，但这里有一些想法：

1. 一些 WPF 和 Silverlight 控件套件是来自已建立的 Windows 窗体套件的端口。在这些情况下，设计人员通常执行最小的移植，因此最终得到与他们移植的 WinForms 代码相同的过程化、非面向绑定的编程模型。我记得评估过这样的 Silverlight 图表套件 - 主要示例看起来与 WinForms 代码完全一样，而不是绑定。
2. 惊人数量的 WPF 程序员似乎没有“明白”WPF 是“所有关于绑定的”（以及样式和模板；通常，WPF 是声明性的而不是命令性的）。查看 Stack Overflow 上询问如何在 WPF 中以命令方式执行操作的问题数量，而惯用的解决方案是声明式执行。
3. 有时设计人员可能认为将特定属性作为绑定目标根本没有用或不理想，例如，因为控件需要对该属性执行神奇的内部操作，或者因为设计人员无法设想任何情况其中属性永远需要数据绑定。
4. 有时 DP 习语与 CLR 属性习语相矛盾。例如，CLR 集合属性通常是只读的（并通过 Add、Remove 和 Clear 方法进行操作）——FxCop 甚至为此制定了规则。但为了可绑定，集合 DP 必须是可读写的。在这种情况下，控件设计者（尤其是过于信任 FxCop 的设计者）可能会发现自己在思考 CLR 习语，尤其是当他们无法想到绑定场景时（“为什么任何人都需要绑定 GridView.列集合？”）。

但这都是猜测和概括：如果您想要一个明确的答案，您真的需要选择具体的示例并在这些控件的支持论坛上提问。