Jon Flanders weights in on the complexity of Windows Workflow Foundation, saying he disagrees with some of the points raised by Brian and Scott . I think he exaggerates a little bit when he says we think it is too complex, I just said it was complex :-). While Jon raises many good points, I don't quite buy his argument. Seems to me he's saying WF is simple bacause, well, it behaves as it was supposed to behave based on the design the WF team chose for the product. Jon does raise the very good point that, as any other technology, you have to understand it in order to use it effectively, which is something I do agree with (see? we do agree on something! ;-)). However, I'll like to explain my comments on WF complexity a little more (though I know it's something Jon and I disagree on ). I expected WF to be a complex technology, because the underlying problem domain is complex. And for what it's worth, complexity is not bad, and I personally happen to like a lot about WF.However, I don't think that going for this complexity is warranted in everycase, which seems like it is what MS is advocating when they raised the "Workflow is Everywhere" mantra. For example, I happen to think that going for the complexity of WF for your website navigation (PageFlows) is unwarranted in most cases, unless you have some seriously complex scenarios to tailor to. There will definitely be a need for good architectural guidelines as to when going with WF is really a good investment. But besides that, my main concern with WF is that it is deceptively simple . Windows Workflow Foundation, for better or worse, is an extremely leaky abstraction, and it shows in several places. In particular, the WF programming model makes it seems as if programming WF was actually simpler than it really is, and manages to hide some crucial aspects of the WF behavioral model so that you might not be aware of them until it is too late and you're about to hit a brick wall at a 100MPH. But let's bring some clear examples of this: Spawned Contexts Scott and Jon brought the Spawned Contexts concept to the table, with Jon saying that they are a very important part of the model. I agree, they are. They are also a direct consequence of the WF design around workflow definitions being prototype instances of the workflow at runtime, and the persitency requirements of workflow. Spawned Contexts are not a problem per se, and they are actually a pretty clever solution to the problems they solve. The real problem is that nothing in the WF programming model forces you to be aware of Spawned Contexts.It is incredibly easy to write code (both in a simple workflow as well as in custom activities) that will appear to work fine at first but that later completely breaks down when spawned contexts are introduced into the mix. The other part of the equation is that it's also not very clear from just looking at a workflow definition what will introduce spawned contexts into the workflow. Sure, perhaps you spot a ReplicationActivity
Read More...