Some things are easier to implement just by hand (code), but some are easier through WF. It looks like WF can be used to create (almost) any kind of algorithm. So (theoretically) I can do all my logic in WF, but it's probably a bad idea to do it for all projects.
In what situations is it a good idea to use WF and when will it make things harder then they have to be? What are pros and cons/cost of WF vs. coding by hand?
The code generated by WF is nasty. The value that WF brings is in the visual representation of the system, although I have yet to see anything (6-7 projects at work now with WF that i've been involved with) where I would not have preferred a simpler hand coded project.
Personally, I'm not sold on WWF. It's usefulness wasn't as obvious to me as other new MS technologies, like WPF or WCF.
I think WWF will be used heavily in business applications in the future, but I have no plans to use it because it doesn't seem like the right tool for the job for my projects.
The major reason I've found for using workflow foundation is how much it brings you out of the box in terms of tracking and persistence. It's very easy to get the persistence service up and running, which brings reliability and load distribution between multiple instances and hosts.
On the other hand, just like forms apps, the code patterns that the workflow designer pushes you towards are bad. But you can avoid problems by writing no code in the workflow and delegating all work to other classes, which can be organized and unit tested more gracefully than the workflow. Then you get the cool visual aspect of the designer without the cruft of spaghetti code behind.
related
http://stackoverflow.com/questions/89353/windows-workflow
Btw, it is just called WF now a days.. http://bloggingabout.net/blogs/erwyn/archive/2006/06/16/12522.aspx
You may need WF only if any of the following are true:
For more details, see Paul Andrew's post: What to use Windows Workflow Foundation for?
Please do not confuse or relate WF with visual programming of any kind. It is wrong and can lead to very bad architecture/design decisions.
I would use it in any environment where I need to work with workflow, however when using it in conjuction with K2 or even SharePoint 2007 the power of the platform is truly useful. When developing business applications with BI specialist the use of the platform is recommended and this would normally only be relevant to streamline and improve business processes.
For the record WF was developed in conjunction with K2's development team and the new K2 Blackpearl is built on top of WF, so is MOSS 2007 and WSS 3.0's workflow engines.
The company I am currently working for set up a windows work flow and the reasons they chose to use it was because the rules would frequently be changing and that would force them to do a recompile of the various dll's etc and so there solution was to place the rules in the db and call them from there. This way they could change the rules and not have to recompile and redistribute the dlls etc.