My Gripes with Windows Workflow
Brian Noyes' post "Understanding Windows Workflow and its complexities" has me thinking.
I know a few people who have given up on Windows Workflow altogether. WF imposes its own paradigm. If your way of thinking is different from the WF way of thinking, you are going to live in a house of pain.
Brian's first complaint is about the designer. I've found the designer to be clunky. There are behaviors you come to expect in Visual Studio, like being able to double-click somewhere and have the designer perform some work. The WF designer never acts intuitively. There are also places where the behavior seems inconsistent - some properties permit data binding and some properties do not. It's not until you learn about dependency properties and meta-properties that this behavior make sense.
Brian's third point was about the HandleExternalEvent activity. Setting up communications between a workflow and its host is a tremendous amount of work, and it's easy to get wrong (a working title for my InfoQ article was "How To Screw-up the HandleExternalEvent activity"). The work doesn't payoff until you see an event arrive for a workflow that has been living in a database table for 8 days. The runtime can re-load the correct workflow and still deliver the event! It's amazing to see this happen, but requires a lot of work to get there.
There are some common gotchas in WF programming:
1) Spawned execution contexts. The rule is that an activity executes once and only once. If you write code that forgets this rule, it's going to hurt!
2) Serialization. You don't need database persistence to see exceptions from the BinarySerializer - spawned execution contexts also make a deep copy of activities using serialization. Make sure those custom properties are serializable!
3) Transactions. It's easy to get MSDTC involved in heavy duty transactions with WF. Just using a persistence service and transactional tracking service at the same time will get the DTC involved (unless a special SharedConnectionWorfklowCommitWorkBatchService is added to the runtime). Something makes me nervous when a class name has 46 characters.
WF isn't as easy as it first appears. It's powerful, but requires an investment of time.