.NET WF4: Should it be in the middle of everything?

Question

I'm working on a new architecture for essentially an n-tier collaborative application (not enterprise-class, just a smallish project with potential to grow significantly) where I'm already trying to discipline myself to use IoC and, to some extent, TDD, and I'm wondering, in general terms, whether it is wiser to just hand-code workflow logic or if I should delve into learning and integrating WF4 (Windows Workflow 4.0, part of .NET 4.0) so that WF becomes literally the controller of the entire application, i.e. the practical C in "MVC" (not ASP.NET MVC but rather the pattern). So should workflow activities in WF4 be the primary controller for a highly expandable/growable web-based collaborative application? Or am I asking entirely the wrong question?

This is a vague question, I'm sure, so abstract answers are as welcome as specific ones.

I am aware that WF4 is a significant rework and redesign of WF3, where much of what made WF3 a poor technology choice has been cleaned up in WF4. For example, as far as I can tell (although I haven't looked very hard, and there's been virtually no coverage on this), WF4 activities are more or less testable with [TestMethod] and mocking (can someone in the know please confirm? .. testability of WF is a huge concern for us). I have very little interest in the diagramming or late-loading via XML with WF, I much prefer to write concrete C# workflow declarations, but if a workflow can be written succinctly in a compiled language and can be testable, I'm tempted to pay attention to it. So if these improvements are there, these among others like improved performance have grabbed my attention about the technology again, whereas I had previously pooh-poohed WF3.

Also, according to Microsoft, WF4 is what Microsoft wants to standardize upon for all the many workflow-driven products in the future, after lessons learned from having different workflow technologies in MS CRM, MS SharePoint, etc. I am certainly curious about betting on a one-size-fits-all feature, but only if implementations can be succinct, type-checked at compile-time, testable, and maintainable.

EDIT: Only answers from those who know WF4 (not WF3) will be considered for "the answer".

Answer 1

No, I would not put it in middle of everything.

I'm currently involved with a project making extensive use of workflow 3. It's not workflow 4, and I understand there are a lot of improvements in WF4, but... workflow is workflow.

I would generally say that it's fun, interesting and beneficial to learn new technologies. You can gain new perspectives and understandings. But in my opinion the project I am working is overusing workflow. It's being used for object persistance, timer-based events and process status tracking. It can do all of these things, but I don't believe that it's adding anything to the system.

I'm definitely cynical based on my workflow 3 experience, but so far I have found workflow to be more difficult to debug, more difficult to integrate, and liable to introduce a lot of race-condition scenarios where multiple workflows are independently active in different parts of my process.

If you don't need to use workflow are not gaining any specific, tangible benefit from using it, then why add further complexity and risk to your system? Just because you 'can' or 'could' use workflow is not sufficient reason. If you want to delve it into then built a toy using it, or maybe throw one or two workflows into your system in non-critical roles.

Consider whether you are utilizing any of the specific and unique features of workflow. E.g. being able to test is not a feature of workflow; it's not going to be easier to test a workflow than a block of code.

There are very few things that you can do in workflow that you can't do in plain code (I say 'very few' because I'm sure there are some, but I don't know of any). You need to weigh up your gains and losses, and built a proof of concept.