One of the first questions I had about Windows Workflow (in .NET 3.0) was how data was moved around between workflow activities. Activities, of course, are the meat of a workflow process in that they define the actual work a workflow will address. So if one activity picks up a useful data value that some other activity will later need, what technique should be used to pass this data between these activities?
Windows Workflow Foundation provides several features that aid in accomplishing this task:
- Activity Properties – each activity may publish it’s own bindable set of properties that can be used as input and output parameters for the activity.
- Workflow Properties – the workflow itself can publish it’s own set of properties.
- Declarative Binding – using dependency properties, properties from one activity can be automatically bound to properties on other activities.
- Workflow Navigation – From within an activity, you can navigate the hierarchy of a workflow process in order to find specific instances of other activities that may have information you need.
These features give you multiple options for moving activity data around within a workflow. However, you must be careful in your implementation since, for example, workflows allow parallel processing and you must be sure to get to the activity instance that you really want. MSDN published a very useful article about these and other related issues here.
To me, the best option is to use declarative binding, for two reasons. The first reason is that declarative binding eliminates any ambiguity about which activity instance you are binding to.
The second reason is to abstract your activity objects from your workflow. When navigating the hierarchy of the workflow, you are making assumptions about how the workflow is structured. Using bindings on properties allows the activity to be more stand-alone and more likely to be reusable. And of course, it allows easier unit testing of the activity.
Second Stanza 
Leave a Reply