Sneak Peek: ASP.NET and Windows Workflow

I’ve been working on an article that will show how to use a Windows Workflow state machine to drive logic behind an ASP.NET web form. Generally, my approach in articles is to use just enough code to reveal a specific concept. I don’t use heavy abstractions or include the safeguards and proven practices we need for production applications.

There is delicate balance to strike when devising sample code, and you can never please everyone. Simple code will find itself cut and pasted into situations where it shouldn’t exist, and the person who has to fix the situation will curse you for being a fool. On the other hand, complex code is frustrating to the person who doesn’t want to tear apart three software layers just to see how to kick start a workflow in ASP.NET.

For the article I’m working on, I could cram 15-20 lines of code into a Page_Load event. I started down this road, in fact, but I began to feel dirty. So dirty, I took a hot shower and came up with something like this:

Now the ASP.NET web form doesn't know anything about Windows Workflow - it only sees a service that interacts with domain objects. Between this service and the WF runtime is a mediator that uses knows how to run workflows and harvest workflow results. A second  service - a transaction service, commits units of work inside the same transaction as the WF persistence and tracking services. The end result is a unit-testable architecture, and relatively clean event handlers in ASP.NET code.  

The result is a more advanced article where the reader will need to understand some of the WF basics before digging through the sample application. I might be leaving out beginners, but I feel the complexity is justified. Now I just need to finish the article, as it is one week behind schedule. It's easy to push back deadlines since I set the schedule!