What is a dependency property?

Question

What is a dependency property in .Net (especially in WPF context). What is the difference from the regular property?

Answer 1

Dependency properties are properties of classes that derive from DependencyObject, and they're special in that rather than simply using a backing field to store their value, they use some helper methods on DependencyObject.

The nicest thing about them is that they have all the plumbing for data binding built in. If you bind something to them, they'll notify it when they change.

Answer 2

The only explanation I found helpful and well written is this one: http://www.wpftutorial.net/dependencyproperties.html

Basically, DependencyProperties differ from regular properties in that they're not just setters / getters for fields in the class, but they retrieve their actual values dynamically during runtime. The SetValue() method of DPs is pretty straightforward and sets the local value of the property to the value you gave it. However, when you try to GetValue() from a DependencyProperty, it will first look for a local value, if none is present (which is viable in DependencyProperties unlike regular properties) it will continue up the logical UI tree until it will find such value. If the framework has reached the top of the tree without finding any local values, it will then use a predefined default value as the property's value.

This method allows DependencyProperties to consume less memory than regular properties since only values that were explicitly set by the user will be stored locally.

And, as mentioned above, DependencyProperties also allow us to bind to them in the XAML code and set triggers on them, which on regular properties is not allowed.

I hope I've managed to clear some of the vagueness :)

Answer 3

http://techpunch.wordpress.com/2008/09/25/wpf-wf-what-is-a-dependency-property/ provides a good explanation of dependency properties both in the context of WF and WPF.

An excerpt:

Key Point – The Value of Dependency Properties Are Resolved

The ultimate goal of a dependency property, like any property, is to manage state. But unlike normal .Net properties, the local property value is not stored in an instance variable.

Instead, dependency properties are registered with the dependency property framework, and the underlying property value is resolved – meaning the value is determined by the dependency property framework based on rules defined by the property registration.

Answer 4

Explanation without code via Analogy (~5 min)

If you don't like stories then save yourself (~5 minutes)

We'll have to go through a few concepts:

• Value Resolution Up the Tree / Property Value Inheritance and
• Multi-Provider support
• Change Notifications

(a) Value Resolution / Property Value Inheritance

Let's use the example of human genes to explain the concept.

Everyone is more or less the same

Human beings have a lot of information associated with them. Countless hundreds and thousands of data is associated with you –

• how many fingers you have,

• how many toes,

• how many BRCA2 genes you have etc

What is the problem we want to solve?

We want to be able to give straight answers to people who ask us about ourselves without lugging around all that information.

So the question is: how can you remember all of that? Well, originally people started writing all this stuff down, but soon they realised they would need to carry around 10 volumes worth of the yellow pages – basically the entire library of Alexandria (in a hard copy format) in their back pocket to be able to answer all those questions: that’s waaaay too much stuff to lug around.

Solution: Store common information in one place

So someone had a bright idea. They noticed that most of the time, the information is the same. e.g. Most people have:

• one heart

• one face etc.

• three BRCA2 genes

There’s no need for every single person to carry around 30 lbs of paper in their back pocket. You can store all of that information in one place, in one a central library. People would be free to walk around without being burdened by carrying that information around.

But there are always exceptions....not everyone has the same blood type, or the same number of hair follicles on their head. If there are differences or exceptions from the norm, then you’d simply carry those exceptions around with you in your back pocket (i.e. in a dictionary), rather than an entire book shelf worth of books. Remember, for the most part, people are very much the same - they share the same values and this rarely changes. If you don’t have exceptions written down in your back pocket, then you can simply refer the interviewer to the data stored in the common repository.

Example: Reporter interviews President Donald Trump**

Let’s try this with an example.

We have an instance of Person: Donald Trump. A news reporter is asking our esteemed President some questions:

“Mr President Trump, how many HIF1A genes do you have?”

The Don checks his back pocket. There’s nothing listed there about how many genes he has. So he simply tells the reporter that he has the default number that everyone else has. "Same as everyone else," says Trump. "You can find your answer in the library". So the reporter simply goes to the library to find out about that particular detail.

“Mr President Trump, how many faces do you have?

Can this value be resolved locally? Looks like this value is resolved locally because in Trumps's back pocket lies the answer: 2 - which is promptly returned to the reporter.

Value resolution up a tree

In reality, things are a little more complicated than an answer either being in the back pocket, or otherwise being held in a central library. There are many intermediatory places which could store the same information and thus, would be ideal candidates to "resolve the property's value". So things might start in the back pocket, then the reporter might have to check a whole bunch of intermediatory places, in ascending order, in order to get the answer. e.g. the reporter might start with other newspapers, then court documents, and failing all of that, if no answer is found, then the answer is the default value contained in the central library.

To simplify it, things are resolved first with the person, and then upwards higher and higher authorities: eventually ending up with either God or the Spaghetti monster as the case may be. In then end, you keep going higher and higher till you get an answer. In the end, all answers get resolved.

Summary

In short, a dependency property is a property that gets resolved either locally or up the UI tree as the case may be. The reason we do this is because UI elements have hundreds and hundreds of properties that would soon eat up your memory if you were to store them as backing fields for each and every single one of them. Because most of these fields never or very rarely change, there is no need to store them as backing fields, and their values can be resolved by going up the tree.

Lastly, you get automatic change notification built in for free.

Granted, the analogy is a bit strained, but I hope it is helpful.

**Still waiting on the (fire) wall Trump promised. Need to keep the Spamicans out.