为什么这么多的wpf控件实现CLR属性而不是依赖属性？ [英] Why do so many wpf controls implement CLR properties instead of dependency properties?

问题描述

是因为控件程序员很懒惰，难以实施还是知识不足？

is it because the controls programmers are lazy, too hard to implement or not knowledgeable?

它们是来自第三方供应商还是Microsoft的自定义控件，非常控件通常具有clr属性而不是DP属性。结果是我无法绑定到它们，并且wpf是否不只涉及绑定？ ：/

Wether they are custom controls from 3rd party vendors or Microsoft itself, very much controls have often clr properties instead of DP. Result is I can not bind to them and is wpf not all about binding? :/

我的下一个问题是，为什么这么多的wpf控件提供视觉部件，但它们不是视觉树的成员？参见wpf datagrid列，标题...

My next side question would be, why do so many wpf controls offer visual parts but they are not member of the visual tree ? see wpf datagrid columns, headers...

您怎么看？

推荐答案

您没有提供您正在考虑的控件的示例，即使那样，也很难了解设计和实现这些控件的人员的动机，但是这里有一些想法：

You don't provide examples of the controls you're thinking of, and even then it would be hard to peer into the motivations of the people who designed and implemented them, but here are a few thoughts:

1. 某些WPF和Silverlight控件套件是已建立的Windows Forms套件的端口。在这种情况下，设计人员通常只执行最小的端口，因此最终获得与他们要移植的WinForms代码相同的过程性，面向非绑定的编程模型。我记得评估这样的Silverlight图表套件-主要示例看起来完全像WinForms代码，看不到绑定。


2. 许多WPF程序员似乎并没有明白 WPF是关于绑定的全部（以及样式和模板；通常，WPF是声明性的而不是命令性的）。看看堆栈溢出的问题数量，这些问题询问如何在WPF中强制性地执行操作，而惯用的解决方案是声明性地执行操作。


3. 有时设计人员可能认为它根本不是特定属性成为绑定目标没有用或不希望有，例如，因为控件需要使用该属性做魔术内部的事情，或者因为设计人员无法设想该属性将需要进行数据绑定的任何情况


4. 有时，DP成语与CLR属性成语相矛盾。例如，CLR集合属性通常是只读的（并且可以通过Add，Remove和Clear方法进行操作）– FxCop甚至对此都有一个规则。但是，为了具有可绑定性，集合DP必须是可读写的。在这种情况下，控件设计人员（尤其是对FxCop信任度过高的控件设计人员）可能会发现自己在考虑CLR习惯用法，尤其是在他们无法想到绑定方案的情况下（为什么任何人都需要绑定GridView。列集合吗？）。

1. Some WPF and Silverlight control suites are ports from established Windows Forms suites. In these cases, designers often perform a minimal port, and therefore end up with the same procedural, non-binding-oriented programming model as the WinForms code they're porting. I recall evaluating a Silverlight charting suite like this -- the main sample looked exactly like WinForms code, not a binding in sight.
2. A surprising number of WPF programmers don't seem to "get" that WPF is "all about binding" (and styling and templating; generally, that WPF is declarative rather than imperative). Look at the number of questions on Stack Overflow that ask how to do things imperatively in WPF, when the idiomatic solution would be to do it declaratively.
3. Sometimes the designer may deem that it simply isn't useful or desirable for a particular property to be a binding target, for example because the control needs to do magic internal stuff with that property, or because the designer cannot envisage any scenario in which the property would ever need to be data-bound.
4. Sometimes the DP idiom contradicts the CLR property idiom. For example, a CLR collection property is typically read-only (and is manipulated through Add, Remove and Clear methods) -- FxCop even has a rule for this. But in order to be bindable, a collection DP must be read-write. In this case, a control designer (especially one who puts too much trust in FxCop) might find themselves thinking in the CLR idiom, especially when they can't think of a binding scenario ("why would anyone ever need to bind the GridView.Columns collection?").

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

But this is all guesswork and generalities: if you want a definitive answer, you would really need to pick specific examples and ask on those controls' support forums.

这篇关于为什么这么多的wpf控件实现CLR属性而不是依赖属性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！