ecently I started working with a client who was interested in using Windows Workflow Foundation (WF) in a custom application. Having never used WF before, I thought it might be interesting to document the experience and my assumptions as I started learning and implementing the technology in production.
I talked extensively to the client, and took copious notes on the client's business rules to develop a general feel for how a workflow might make sense in the context of the application. Later, I went back to my desk and created some clean, crisp Visio diagrams with processes and decision branches and many lines and arrows. Quite satisfied with myself, I showed this to the client. After we discussed and tweaked the flow of the diagram, we reached an agreement on the details and I went back to my desk, ready to start on my first workflow.
At this point I ran headlong into my first brick wall.
The Workflow Designer Is Not Visio
The sooner you accept this fact, the easier your life will be—or at the very least, you will have slightly more realistic expectations. No matter how pretty you make your process flowcharts and diagrams in Visio, they will bear little or no resemblance to what you end up with in the Workflow Designer.
In fact, you can do a number of things in Visio that you simply can't do in the Workflow Designer, such as controlling the placement and visual flow of your workflow activities. Take a look at Figure 1 and Figure 2 to see what I mean.
|Figure 1. A Visio Workflow: Visio diagrams let you control the placement and visual flow of workflow activities.||
|Figure 2. A Windows Workflow Foundation Workflow: Although functionally equivalent to the Visio diagram in Figure 1, it's easy to see why placement and visual flow matter.||
After recovering from the initial shock of seeing my beautiful workflow rendered as something less aesthetically pleasing, I went through the diagram one activity at a time and proceeded to start giving everything meaningful names. Some activities would require code, while others were merely conditional branches and terminators, so I gave them all easily readable and recognizable names. To simplify tracking, I gave the code activities the same name as their code behind routines. Some of my if/else activities shared a name with another activity (unintentionally.)
At the end of the day, I saved everything and went home, pleased with my progress. I didn't bother doing a build at this point, because I hadn't actually written any code, and the designer hadn't complained about anything.
The very next morning, I learned my second Windows Workflow lesson.
What's in a Name?
As it turns out, there's quite a bit in names, apparently. The workflow designer will let you use the same name in several different places (activities, properties, methods, etc.) without complaining. You'll get errors at build time, but by then it could be a huge mess to untangle.
One example of where this can really get you in trouble is when you give a code activity the same name as the code behind method that it executes.
This is a perfect illustration of why naming conventions are useful. For example, you could prefix your code activities with "ca" to differentiate them from the code behind methods they call.
Visual Studio also provides a Generate Handlers link in each activity's property sheet. Selecting an activity and then clicking this link generates the most likely event handler in the code behind file. However, some of the names it generates are less than elegant. Of course you're free to change the names and remap the activity, via the property sheet—but that's exactly how I got myself in trouble and learned my third Windows Workflow lesson.
|Editor's Note: This article was first published in the March/April 2009 issue of CoDe Magazine, and is reprinted here by permission.|