Wednesday, August 20, 2008

WorkflowRuntime object

On chapter 1 of the book Windows Workflow Foundation Step by Step, the author states that “there can be only a single instance of the WorkflowRuntime per AppDomain”. When I was reading the book, I didn’t found this odd because it makes some sense. You only need one runtime.

In a recent project, however, I was presented with a scenario where I needed a different behaviour from the WorkflowRuntime when using multiple workflows. Simply put, I had 3 different workflows in the same AppDomain and I wanted the WorkflowRuntime to persist one of them and not the others. The only logical way to accomplish this behaviour was to implement myself a persistence service. Of course, I could also create another AppDomain and run another WorkflowRuntime in the new AppDomain but I don’t like this “workaround”.

Since I was short on time, after I googled a little I found that you can have more than one WorkflowRuntime per AppDomain. And this helped. Two WorklflowRuntime objects, one using the persistence service and the other one not using it. Yes, this leads to more resources consumption (the WorkflowRuntime isn’t a “cheap” object) but it was the quickest solution and I wasn’t concerned with performance.

Despite this “multiple WorkflowRuntime objects per AppDomain” feature, I still agree with the author of the book (Kenn Scribner) when he states that we should use a WorkflowRuntime Factory (Singleton and Factory patterns).

Here’s the errata page for the book: