Understanding the Role of Dependency Properties

Dependency Properties Overview

Given all of these similarities, why does WPF define a new term for such a familiar concept? The answer lies in how a dependency property is implemented within the class. You’ll see a coding example in just a little bit; however, from a high level, all dependency properties are created in the following manner:

• First, the class that defined a dependency property must have DependencyObject in its inheritance chain. 
• A single dependency property is represented as a public, static, read-only field in the class of type DependencyProperty. By convention, this field is named by suffixing the word Property to the name of the CLR wrapper (see final bullet point). 
• The DependencyProperty variable is registered via a static call to DependencyProperty.Register(), which typically occurs in a static constructor or inline when the variable is declared. 
• Finally, the class will define a XAML-friendly CLR property, which makes calls to methods provided by DependencyObject to get and set the value. 

Once implemented, dependency properties provide a number of powerful features that are used by various WPF technologies including data binding, animation services, styles, templates and so forth. In a nutshell, the motivation of dependency properties is to provide a way to compute the value of a property based on the value of other inputs. Here is a list of some of these key benefits, which go well beyond those of the simple data encapsulation found with a CLR property:

• Dependency properties can inherit their values from a parent element’s XAML definition. For example, if you defined a value for the FontSize attribute in the opening tag of a <Window>, all controls in that Window would have the same font size by default. 
• Dependency properties support the ability to have values set by elements contained within their XAML scope, such as a Button setting the Dock property of a DockPanel parent. (Recall from Chapter 28 that attached properties do this very thing, as attached properties are a form of dependency properties.) 
• Dependency properties allow WPF to compute a value based on multiple external values, which can be very important for animation and data-binding services. 
• Dependency properties provide infrastructure support for WPF triggers (also used quite often when working with animation and data binding).

The only time when you would need to build your own custom dependency property is when you are authoring a custom WPF control. For example, if you are building a UserControl that defines four custom properties and you want these properties to integrate well within the WPF API, you should author them using dependency property logic. 

Specifically, 

• if your properties need to be the target of a data-binding or animation operation, 
• if the property must broadcast when it has changed, 
• if it must be able to work as a Setter in a WPF style, 
• if it must be able to receive their values from a parent element, 

a normal CLR property will not be enough. If you were to use a normal CLR property, other programmers may indeed be able to get and set a value; however, if they attempt to use your properties within the context of a WPF service, things will not work as expected. Because you can never know how others might want to interact with the properties of your custom UserControl classes, you should get in the habit of always defining dependency properties when building custom controls.