Thoughts on Workflow Foundation 4.0

In this post, I want to show my personal feelings working with WF 4.0, not a technical post. During my experience, I found many challenges to sort, so these conclusions may be interesting for people who is thinking to use this framework to use some complex things.

First, the context, where I pretended to use WF, was hosting a designer in a WPF application to enable users design its own diagrams and run them. In a previous stage, I started using Sequence diagrams, but finally I used Flowchart diagrams because they were more flexible in a user point of view. So, I could test these two kind of diagrams that WF 4.0 offers.

Composition instead inheritance

Concretely, to modify the design of the FlowDecision activity (IF statement) to enable to an user be able to write the condition without using the properties panel. The first thought of a good programmer is to extend FlowDesigner design to assign the modified XAML. Result: No possible. Explanation: "WF 4.0 bets for composition, not for inheritance and there is no plans to change." by WF 4.0 architect. Consequences: Not only in this scenario, but in other many ones where it is necessary to do complex workarounds to perform simple things. For example, to modify some little thing in the current either Flowchart or Sequence diagram or in the Validation context.

Of course, inheritance is not the solution for everything, but neither composition. I think WF 4.0 should be more flexible in this term.

Internal classes


Internal keyword is used to hide some classes to other users in order to avoid bad consequences. Therefore, these internal classes cannot be instantiated to execute some method or see some properties.

In WF 4.0, this keyword is very extended in many classes (overall designers, validators, etc). So, if you want to have an instance to check something, you cannot. For example, I included a panning mode in the diagram to enable to the user scroll along the diagram using a hand mouse way. The problem was coming when I need to identify that the designer where users clicked, it was the root diagram (the designer of the root diagram it was an internal class...).

The correct usage of the internal keyword is to hide some classes because probably something inside these classes will change and therefore using this keyword, avoid using these classes and bad consequences in third teams after changes.

Validating activities


Reading WF 4.0 documentation, the validation for activities is done within the overrided CacheMetadata method calling to method AddValidationError from the activity context. The CacheMetadata method, like its own name indicates, is used to cache some properties within activities into the metadata for increasing the performance. So, validating an activity on this way makes no logic sense, it should be neither the proper place nor the right way. Furthermore, if you want to include a warning instead of an error, you still have to call to the AddValidationError and set a flag to true, it seems very dirty.

In previous versions of WF, there was an attribute for the custom activities to set a concrete implementation of the validation what has more sense. I have no idea the reason for this change to worse in my humble point of view.

ModelItem entities


WF 4.0 builds a class structure in each workflow execution which mainly it is focused in a Model Item tree structure. The advantage of this is to expose the data in an efficient and intelligent way that is being edited along the execution. The problem arrives when you want to link your designer with the activity in code (using the pattern MVVM where - ViewModel would be the activity class and the View the designer), then the development is very confused and dirty because you need to research where are the stuff that you require to show.

Output execution

WF 4.0 has two ways to execute programmatically a workflow: (1) using WorkflowInvoker and (2) using WorkflowApplication. On both cases, you run an activity and you only obtain the output of the out arguments from the main activity. The problem is because if you have a flowchart or a sequence that is a composition of activities, you cannot retrieve the out arguments from all involved activities. Actually, you obtain no output.

Online documentation

We are used to have a great support on .NET technologies thanks to many forums and websites. Nevertheless, in the case of WF, there is not much information and almost all of them does not play in complex scenarios (except in the case of some projects in CodeProject site).


Summary

I feel that WF 4.0 is in a very immature stage where seems development is focused only in a concrete scenarios. Anyway, apart of of the inconveniences, it has very nice features that we take in advantage. I just hope architecture is getting better in next versions to involve more complex scenarios.