OdeToCode IC Logo

Dependency Property Notes

Friday, July 28, 2006

I've run into dependency properties in both Windows Presentation Foundation and Windows Workflow Foundation. In trying to understand what they do, I ran across Drew Marsh's excellent introduction - "Avalon: Understanding DependencyObject and DependencyProperty". Drew's article has a WPF slant and I've mostly been seeing dependency properties from the workflow side.

In WF, dependency properties enable three features:

  • Attached properties
  • Activity binding
  • Meta properties

The attached property story in WF is similar to the attached property story in WPF - a parent object can add additional state to the children it manages. A WPF grid will attach Row and Column properties to its children. The dynamically attached properties allow the grid to store layout state in each child. In WF, the Conditioned Activity Group can attach a When property to each child. The When property holds a condition for the CAG to evaluate before running a child activity.

Activity binding gives a dependency property an ActivityBind object to evaluate when asked for its value. The ActivityBind can point to other fields, properties, or methods of activities inside a workflow. One activity could bind its input properties to a previous activity's outputs. Binding makes the data flow a part of the workflow model.

The behavior of meta properties caught me off guard. There are two types of dependency properties in WF activities: meta properties and instance properties. We set meta properties at design time and cannot change their value at runtime (they can't use binding, either). I think meta properties exist to guarantee the integrity of an activity. At runtime, I can't change the InterfaceType of a CallExternalMethod activity and screw up the rest of the parameter bindings because InterfaceType is a meta-property.  

Dependency properties are easier to understand once you see the use cases. You have to wonder if we'd be talking about dependency properties a all if the mainstream CLR languages were more dynamic.