What is the benefit of using Windows Workflow foundation (WF) versus rolling your own workflow framework?
From what I can tell, WF only provides a pretty bare-bones runtime engine, a bunch of classes, and a schema (XAML-based) for defining workflows. All the hard stuff such as persistence, providing a host process for the runtime, and implementing distributed workflows (across processes) is left up to you.
Plus there is a learning curve to using WF... if we created our own workflow framework we would simply leverage skills that all developers already have (C#, XML, SQL, etc).
I saw this blog from an MS evangelist which tries to explain why we should use WF:
IMO it doesn't do a good job of convincing because it just states that it helps "developer productivity", while admitting that developers could roll their own.
Can any of the smart folks here come up with a better reason?
SUMMARY FROM ANSWERS GIVEN BELOW:
I think the most convincing reason is that using a standardized workflow platform such as WF (versus rolling your own) will allow you to leverage current and future tooling such as the Visual Designer, provided by MS and third parties.
Also because it is part of the MS stack of .NET based technologies, it will likely have better integration/migration path with future MS technologies (such as Azure).
Finally, the number of developers with WF experience will increase (as it will benefit them career-wise), turning it into a basic commodity skill such as SQL or HTML, meaning it will become easier to find people who can start working with it with minimal ramp up time.
The choice to use WF takes some evaluation and I'm going to try and provide a fairly comprehensive list here on what the pros and cons are. Keep in mind that if you're going to use WF don't use anything other than WF4+ because it was rewritten and is significantly vetted past its predecessors.
Pros
- Cost
- Flexibility
- Durability
- Distributability
- Future
Cost
The cost of WF is important to note when comparing it against other paths. Those paths may include BizTalk, an open source code based framework like Objectflow, or even rolling your own. Bear in mind that unless you need something significantly simplistic, rolling your own would be the most expensive approach every time. So, if you need a sizable piece of functionality but also need control over the source code I would recommend an open source framework.
Flexibility
WF is a very flexible framework in contrast with a framework like BizTalk. In WF you can write your own custom activities and do what you need to do outside of the framework - this really gives you the power you need.
Durability
WF includes a very powerful durability framework. It's durable in the sense that the state of a workflow can be persisted, the workflow can be set idle (to preserve resources), and then recalled later. But, that durability goes a lot further because it's already setup for durability across a host farm. In other words a workflow can be started on one host, persisted, and then recalled on another host.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Distributability
WF is already setup to be distributed across a host farm.
Assumes that the workflows are hosted via a web service (i.e. WorkflowService).
Future
WF is the replacement orchestration engine for BizTalk and is in fact developed by the same people that built BizTalk. Therefore WF has a bright future in the Microsoft stack. In fact, right now Microsoft is working on building individual components to replace every feature of BizTalk with components. For example, Windows Server AppFabric (and more specifically the plug-in to IIS) is the replacement for the monitoring services that exist within BizTalk today.
Why is Microsoft doing this? Because BizTalk isn't really well suited for the cloud because it's one massive install, whereas the components they are building could be deployed to a cloud solution.
Cons
- Flexibility
- Monitoring
Flexibility
WF's flexibility can also be its pitfall because sometimes you don't need the flexibility that it provides and thus spend more time building stuff that you would otherwise want to just be included. Sometimes you need a framework that makes a lot of assumptions and maybe works off of convention instead (e.g. MVC). However, generally speaking I have found that this isn't true when coupling the WF4 framework with the open source extensions provided by Ron Jacobs.
Monitoring
The monitoring for WF is still very young and this is its biggest pitfall. However, this will advance very quickly over time and in the meantime you can build your own monitoring tools with custom tracking mechanisms.
Resources
Your best resource is Ron Jacobs. I have never met somebody that is so willing to help the community of developers that have to use Microsoft's frameworks than him. Believe me, he's provided a vast amount of information surrounding WF via numerous channels, just get on Google and check it out.
The main reasons I can think of to lean towards using WF over another workflow framework are:
- Microsoft is supporting it as a core part of the framework, so it can/will be easier to integrate into their other technologies like Sharepoint and Azure "cloud applications"
- The tooling is likely to improve and be really slick in another few versions, which should improve developer productivity
I have had to create Workflow activities at my job, and I can't even tell you the answer.
One not very valid reason is that invalid values/inputs can be determined and refused at design time for workflow diagrams, and so compile-time errors basically don't exist (assuming all that boilerplate code you wrote has no compile-time errors).
Short answer: it's free and it gets the job done. If you can roll a better framework for managing workflow and want to spend your time on it, by all means do. But consider that your time is worth money, so how much money are you willing to commit to building a better framework for managing workflow? I could see that getting expensive.
Also, I'm pretty sure that persistence (to disk or SQL) is handled out of the box.
There is some reasonably nice designer support in Visual Studio that I'd rather not have to roll for myself, and it's a framework supported by someone else rather than me, meaning someone fixes the architecture bugs and does the main testing, leaving me to test just my workflow. I mean, I could roll my own versions of GDI+ calls, but I'd rather not. Same goes for my own serialization framework, XML parser, or some other element of the .NET framework.
When it comes down to it, these things are provided as a toolkit. Whether you choose to use a tool or not depends entirely on the problem you're solving, the suitability of the tool, and the time and resources you have available to achieve the goal.
Its a new technology Or you can say its latest with a promise of constantly updating features.
It respects the previous working environment and uses it and add those features which are very helpful with regards to the development of the long running programs(large projects).
It produces all that features directly into the hands of the developer which were previously running at the back lacking the interaction between the inner core concepts and the programmer.
Yeah its a little complex but also it provides more power in the hands of the programmer.
You can expect better frameworks and features in the coming future. Its the future of the programming so better we start learning it today.
来源：https://stackoverflow.com/questions/513657/why-use-windows-workflow