views:

46

answers:

2

I understand that dependencies properties serve a major purpose in WPF. However I do not get the reasons behind the restriction that in binding, the target property must be a dependency property. Why can't it be any property?

A: 

A simple search in google with DependencyProperty yields some results, which you might find relevant. For instance: http://blog.hackedbrain.com/articles/UnderstandingDependencyObjectAndDependencyProperty.aspx

And I guess one of the reasons would be context. Binding is built into the infrastructure of WPF, but a C# class property does not belong there. Inorder for the WPF infrastructure to find bindable properties you must declare them in code. Also if you declare your properties, you give important metadata for the WPF infrastrtucture.

Although I do agree that it would be easier if it were possible to bind to regular properties, but this is certanly a case of don't bother your precious brain with minor details...

Marko
Actually i googled a lot, but didn't find anything convincing. The problem is we can use OneWayToSource and use a normal property act like a target. So it looks like that only a normal to normal property binding is not allowed. The rule should be at least the target or the source should be dependency property. If this is the case then the statement 'target property should be a property' doesn't really hold up well.
thewpfguy
A: 

If you're interested, you might open up Reflector and take a look at some of the code related to dependency properties and the binding system in the framework. There is a lot of tricky stuff going on to allow robust, performant resolution of property paths and propagation of changes to dependency properties. Having a standard infrastructure also allows for management of more complex use cases, such as updating a dependency property from more than one source and resolving the priorities. This comes up frequently when animating a property that has its default set by a style, for example.

The other nice thing with dependency properties is that they internally encapsulate a lot of behavior (such as notification, validation and coercion), which means if you see a dependency property, you know that certain behavior will definitely be supported. This is in contrast with INotifyPropertyChanged, where the class implementer may or may not be supporting the interface as advertised. This means less work for class developers.

Dan Bryant