Windows Workflow Foundation 3
To use dependency properties or not
I'm looking for guidence and best practices for defining workflow properties. I've seen examples and comments where workflow properties are defined as normal .NET properties. I've seen an equal number of examples and comments that use dependency properties within the workflow. I know that you need dependency properties within custom activites in order to permit design time binding to other activities. What about the workflow properties? When do I need dependency properties in my workflow? When can I just use normal .NET properties? What "features" do I give up if I don't use dependency properties? Are the benefits or problems with either approach?Thanks in advance.Bruce BukovicsAuthor of .NET 2.0 Interoperability Recipeshttp://www.apress.com/book/bookDisplay.html?bID=10116
Hi Bruce, The three main reasons for using DependencyProperty over a normal .NET property are: Activity data-binding Defining activity metadata Attached properties I think it's pretty clear why you need dependency properties to leverage ActivityBind functionality, so I won't go into this topic here. One key feature that dependency properties carry is defining metadata properties. An activity metadata property is a property whose value is immutable at runtime - this property can only be assigned a value during design time. This is extremely useful in situations where changing a property's value at runtime would violate certain assumptions or functionality. Some examples of metadata properties are the 'Name' and 'Enabled' properties on all activities. Another key gain of metadata properties is that since their value is immutable at runtime, there is no need to serialize these properties as part of workflow persistence, which reduces the persistence footprint. Below is an example of a metadata property. public static readonly DependencyProperty MyMetadataProperty = DependencyProperty.Register( "MyMetadata", typeof(string), typeof(Workflow1), new PropertyMetadata(DependencyPropertyOptions.Metadata)); Attached properties is another feature acquired by using dependency properties. A dependency property that is defined using the 'RegisterAttached' method is referred to as an attached dependency property. These properties can be set on activities that do not define this property as an extension to their existing property set. One example is the ConditionedActivityGroup (CAG) 'WhenConditionproperty.' This property, of type ActivityCondition, is set on all children of CAG in order for CAG to determine the execution pattern for its children. The children need not define or know about the CAG property because it is specific to CAG, but they can carry the value for this property that CAG defines. Below is an example of an attached property: public static readonly DependencyProperty MyAttachedProperty = DependencyProperty.RegisterAttached( "MyAttached", typeof(string), typeof(Workflow1)); As for defining dependency properties on your workflow, that all depends on your use cases. A workflow is really no different than a custom activity. Perhaps your workflow will execute as the root activity in some scenarios, in which case any properties it defines are workflow parameters it exposes, and can just as well be either .NET or dependency properties. But in other cases, maybe this workflow will be an activity in yet a larger workflow, in which case it may be useful to bind the properties to data in this larger workflow, in which case it would be useful to define them as dependency properties. It all depends on how exensible you need your 'root' activity to be. Overall, chances are that if you do not need functionality beyond that of a .NET property, then you probably don't need a dependency property. -Angel
Hi Bruce, The three main reasons for using DependencyProperty over a normal .NET property are: Activity data-binding Defining activity metadata Attached properties I think it's pretty clear why you need dependency properties to leverage ActivityBind functionality, so I won't go into this topic here. One key feature that dependency properties carry is defining metadata properties. An activity metadata property is a property whose value is immutable at runtime - this property can only be assigned a value during design time. This is extremely useful in situations where changing a property's value at runtime would violate certain assumptions or functionality. Some examples of metadata properties are the 'Name' and 'Enabled' properties on all activities. Another key gain of metadata properties is that since their value is immutable at runtime, there is no need to serialize these properties as part of workflow persistence, which reduces the persistence footprint. Below is an example of a metadata property. public static readonly DependencyProperty MyMetadataProperty = DependencyProperty.Register( "MyMetadata", typeof(string), typeof(Workflow1), new PropertyMetadata(DependencyPropertyOptions.Metadata)); Attached properties is another feature acquired by using dependency properties. A dependency property that is defined using the 'RegisterAttached' method is referred to as an attached dependency property. These properties can be set on activities that do not define this property as an extension to their existing property set. One example is the ConditionedActivityGroup (CAG) 'WhenConditionproperty.' This property, of type ActivityCondition, is set on all children of CAG in order for CAG to determine the execution pattern for its children. The children need not define or know about the CAG property because it is specific to CAG, but they can carry the value for this property that CAG defines. Below is an example of an attached property: public static readonly DependencyProperty MyAttachedProperty = DependencyProperty.RegisterAttached( "MyAttached", typeof(string), typeof(Workflow1)); As for defining dependency properties on your workflow, that all depends on your use cases. A workflow is really no different than a custom activity. Perhaps your workflow will execute as the root activity in some scenarios, in which case any properties it defines are workflow parameters it exposes, and can just as well be either .NET or dependency properties. But in other cases, maybe this workflow will be an activity in yet a larger workflow, in which case it may be useful to bind the properties to data in this larger workflow, in which case it would be useful to define them as dependency properties. It all depends on how exensible you need your 'root' activity to be. Overall, chances are that if you do not need functionality beyond that of a .NET property, then you probably don't need a dependency property. -Angel
Thank you Angel for your clear summary.Bruce
Related Links
enabling/disabling activities via policy
missing method exception in CallExternalMethodActivity
Performance of runtime creation and execution rules in WF
Error in my WorkFlow (Response.Redirect)
Approving Multiple Records in one go..
Dynamic Update
The Executing event of all my SetStateActivity objects dont fire
Design guidance needed for WWF application
Custom pub/sub service for WF message correlation
Is there any event get fired when I changed the content in the workflow designer?
Subscription handler threw System.FormatException
How can I designate string[] field as returnValue for ReceiveActivity?
is the "workflows in memory" performance counter failing to be reset?
Creating a workflow dynamically
writing non-persistance data to Oracle from a workflow app
Is Workflow Foundation a good fit for multiple workflow processes