Why do so many wpf controls implement CLR properties instead of dependency properties ?

Question

Hello,

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

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? :/

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...

What do you think?

Answer 1

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. 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.