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

WF custom persistence once again
Hands on Labs 2.2
WF Virgin
Error in the Hands on lab 09
Workflow Designer
How do you load XOML only State Workflow in WFPad for WWFBeta 2.2 (with namespace for codebehind assembly, and activities)?
invoke sub StateMachine workflow
Using WWF to model and support "Tech Trees" in RTS games
RuleConditionDialog and intellisense
Workflow Persistence & Event Arguments
PersistenceService - Transaction Timeout
SimpleExpenseReport
SQLTrackingQuery from Workflow
CreateWorkflow failing validation
xbox live mic help
download code samples of Microsoft press' windows workflow foundation step by step - Kenn Scribner

Categories

MSDN
Visual Studio Development
Game Development
BizTalk Server
Commerce Server
Dynamics
Orchard
ScriptJunkie
Open Specifications
Archived Forums T-U
Internet of Things
Cortana
Forums Issues (not pro...
Visual Basic
Visual Studio Tools fo...
Tools for Apache Cordova
Register and Manage Ac...
Publishing Windows Sto...
Windows Desktop Develo...
General Windows Deskto...
Windows Desktop Develo...
Windows Desktop Optica...
Windows Desktop SDK
Windows Hardware WDK a...
Development with the W...
Message Analyzer
Word for Developers
Open XML Format SDK
Office 365 for Developers
SharePoint 2013 - Deve...
SharePoint 2010 - Usin...
SharePoint 2010 - Search
SharePoint Legacy Vers...
Azure Management Portal
Azure Pack
Azure Mobile Apps
Azure Scheduler
Azure Key Vault
Azure Log Analytics
Azure SQL Data Warehouse
Azure Database for Pos...
Publishing Apps for th...
Windows Presentation F...
Team Foundation Server...
Team Foundation Server...
Visual FoxPro General
BizTalk Server General
Microsoft Device Emulator
Visual Studio Smart De...
SQL Server Data Access
SQL Service Broker
SQL Server Compact
SQL Server Spatial
SQL Server Distributed...
SQL Server 2012 Analys...
SQL Server 2012 Report...
WebsitePanel - Enterpr...
Office Live Basics, Es...
Office XML, ODF, and B...
Silverlight Installati...
Programming Silverligh...
Silverlight for Window...
Designing with Silverl...
Visual Studio Report C...
Retired SharePoint Exc...
Project Online General...
Audio API and Programm...
Azure Troubleshooting,...
Building Windows Store...
Deep Zoom Composer
Direct3D 10
HD DVD Interactivity A...
HealthVault Data Types
Innovate on Office
ISV Community Days
JScript for the .NET F...
Managed Extensibility ...
Office Development wit...
Office Live Small Busi...
Popfly Bugs and Sugges...
Popfly Explorer
Regular Expressions
Parallel Programming w...
Search Server: Federation
Search Server: Frequen...
Server Core Developers
Silverlight (formerly ...
SQL Azure Labs Support
Visual Basic Interop a...
Visual C# Express Edition
Visual C++ Express Edi...
Visual C++ IDE
Visual Studio LightSwi...
Visual Studio Team Sys...
Visual Studio Online "...
Web Sandbox - General
Windows Desktop Vista ...
Windows Developer Prev...
Building Windows Store...
Windows Phone Preview SDK
Microsoft Partner Cent...
Microsoft R Server

Resources

Encrypt Message



code
soft
python
ios
c
html
jquery
cloud
mobile