Categorizing and Developing Custom Activities and Workflows
Developers working with WF often come across situations where they have to author custom activities and workflows. The questions that immediately strike:
- Should there be a single assembly for all the activities?
- Should there be an assembly for each activity?
- How should the activities be categorized?
A decision on the developing the assemblies can be taken based on what’s common among the activities or workflows.
For example, if we have 3 activities/workflows which belong to the same domain or a module, author them under a single assembly. We may decide to make a single activity as an assembly if the functionality of such an activity is unique. An example for this can be “EmailActivity”.
Same applies to workflows as well. In case of modifications to the category of the workflows/activities, the “Type” can be moved from one assembly to another without recompiling the clients that consume the initial assembly. This feature in .NET is called Type Forwarding.
However, for both custom activities and workflows, business requirements play a vital role to categorize them.
Based on the business requirements,
1. Identify at a high level all the possible workflows.
2. Find what is common among them and categorize them.
3. Identify the custom activities that should be created.
4. Repeat Step 2.
This may not be a problem for a small set of workflows/activities. When there are many workflows, which cut across an Enterprise, this can prove to be quite a task.
The ultimate goal should be to completely avoid redundancy and establish an optimal authoring pattern of activities and workflows.
