I'm writing this article in response to a newsgroup posting where the reader states:

I am confused by this concept : why it is designed like this? Is there any document on it's design purpose and intention? The document in Avalon CTP is not helpful.

I'm sure a lot of people either are, or will be, wondering the same things, so I figured I would whip together this article for future reference.

The DependencyObject/ DependencyProperty design actually exists for several reasons all of which I'll ultimately touch on within this article, but let's start with one of the main concepts for which this design exists known as "attached properties". You'll encounter the concept of attached properties almost immediately as you start to use Avalon. Attached properties are dependency properties that other classes declare that can then be applied to any class you will ever throw into the Avalon mix. Let's look at one of the simplest examples of attached properties which involves positioning an item on a Canvas. Canvas has four dependency properties regarding positioning: TopProperty, BottomProperty, LeftProperty and RightProperty. Now, let's say we want to just throw a random UI element onto a Canvas. That UI element's class has no prior knowledge of the existence of the Canvas class or how it chooses to position the elements it contains. Therefore, when I want to put that UI element "into" a Canvas, I need to decorate it with Canvas specific dependency properties to get it to lay out correctly.

Right about now you're probably thinking "Well why not just have base class for all UI elements with Top, Bottom, Left and Right properties?". Well the answer to that is simple if you consider a different layout container such as the Grid. The Grid doesn't just layout things at a certain static X,Y coordinate like the Canvas. It uses rows and columns and automagically positions contained elements based on all the contents of the columns (for X) and rows (for Y). So, to accomplish this, the Grid offers the following dependency properties for positioning instead¹: ColumnProperty and RowProperty.

So the next question is: How do these properties get applied to arbitrary classes? Well first off, the classes obviously need to be DependencyObject subclasses. From the consumer point of view, DependencyObject is little more than a glorified Hashtable². It's job is to store the current values of any DependencyProperty that is ever applied to it. Setting a dependency property is simple:

// Create a button
Button myButton = new Button();

// Button ultimately derives from DependencyObject, so let's set 
// some properties so that it can be positioned on a Canvas!
myButton.SetValue(Canvas.TopProperty, new Length(100, UnitType.Pixel));
myButton.SetValue(Canvas.LeftProperty, new Length(100, UnitType.Pixel));

// Add the button to a canvas and it will be positioned at 100,100
myCanvas.Children.Add(myButton);

Actually, you know what? That's the long winded version because Microsoft has defined a well-known pattern for manipulating attched properties that make it a little easier for us. The pattern basically says that the class that owns the dependency property should provide static accessor methods to get/set the value on arbitrary DependencyObject instances. So let's look at that version:

Button myButton = new Button();

Canvas.SetTop(myButton, new Length(100, UnitType.Pixel));
Canvas.SetLeft(myButton, new Length(100, UnitType.Pixel));

myCanvas.Children.Add(myButton);

Hmmm... wait, that's a long winded version too!!! Why write any C# at all? Let's see how this pans out in XAML!

<Canvas ID="myCanvas" xmlns="http://schemas.microsoft.com/2003/xaml">
  <Button ID="myButton" Canvas.Top="100" Canvas.Left="100"/>
</Canvas>

Remember that pattern I just mentioned? Well XAML relies on it and translates the Canvas.Top attribute syntax to a Canvas.SetTop call.

Ok, this all seems simple enough now that we've been introduced to it right? So, what's the big deal? Well, wait... we've only scratched the surface with the introduction of attached properties. Attached properties aren't the only place that dependency properties should be used. I just decided to started with them because they demonstrate one of the key features that DependencyObject enables, which is the ability to tack infinite amounts of data onto existing objects without them ever having to know about it in the first place. So, let's look at a simpler scenario for dependency properties now, the Canvas.HeightProperty. This could have easily been designed as a plain vanilla .NET instance property of type Length on the Canvas class and nobody else will ever apply this property to anything but a Canvas, so why go through the trouble of making it a dependency property? Point of fact, it still does appear as an instance property on the Cavas class, but the reason it's defined as a dependency property is simple: to gain generic support from Avalon in terms of services. The "big deal" once you use dependency properties is that Avalon can also offer many services to your DependencyObject subclasses now without having to know about their custom implementation details (in this case Canvas.Height ). Perhaps the easiest service to demonstrate, which is probably also the most prominent in Avalon, is animation. Any dependency property can be animated. Let's take that sample we've been working with and animate the attached property a little bit:

<Canvas ID="myCanvas" xmlns="http://schemas.microsoft.com/2003/xaml">
  <Button ID="myButton" Canvas.Left="100">
    <Canvas.Top>
      <LengthAnimation From="0" To="100" Duration="2"
         RepeatDuration="Indefinite" AutoReverse="True"/> 
    </Canvas.Top>
  </Button>
</Canvas>

This will animate the button up and down from 0 to 100 (pixels) over a two second period. Now admittedly, I probably wouldn't want to animate the position of a Button in the real world, but that's actually the point that I'm driving at. This could just as easily be a Rectangle or another Canvas or even my own custom control! The positioning of the element on the Canvas and animation of it's properties is done exactly the same way for any DependencyObject subclass that is ever written from now until eternity.

Ok, ok... I can hear the masses screamning: "Bah! Animation, who needs it!?". Fine, fine... what about the rest of these services that are based on dependency properties then?

So, that's it! Hopefully this article helps you to understand the necessary level complexity that is introduced by the DependencyObject/DependencyProperty model. Without DependencyObject/DependencyProperty, the only way to achevie the same type of generic behavior in .NET would be through something like reflection which we all know has serious performance side-effects. The design enables infinite levels of extensibility and provides powerful services for your custom classes which allow other developers to use them in ways that you may never have even imagined.

¹ Grid is more complex than this, but for purposes of this example this is all that is needed to undersand.
² In actuality, the design of DependencyObject is more complex with great consideration for performance.
³ A style can actually get quite a bit more advanced when it defines a VisualTree
⁴ For more on cached properties, check out this section of the SDK