Where is Windows Workflow Foundation used?

Question

Is WF used at user interface or business layer? If at UI layer, then does someone coding in business layer even need to use or learn it?

Answer 1

WF is the interface to the buisness layer.

Workflows are a declarative way of writing programs by linking together pre-defined activities rather than an imperative programming model of writing lines of code. IN addition, you have many graphical tool that allow you to wrtie workflows. shuch as black pearl, K2 and sharepoint designer.

They are very much used and are well worth learning. I started using then in sharepoint and ms crm. I now always look to workflows to solve my common problems.

here are a few links: mirosoft msdn.microsoft.com/en-us/netframework/default.aspx Wkik: http://en.wikipedia.org/wiki/Windows%5FWorkflow%5FFoundation

Answer 2

Chris offered a great answer, so I'll take a different tack. Workflow is really not the same as logic. Workflows are generally compositions of logic, which makes them a complimentary contributor to the whole. Where a business component nicely encapsulates a single piece of business rules or behavior, a workflow composes multiple business components, rules, and behavior to meet the needs of larger, longer-running business processes.

Workflows can fit anywhere, filling process needs for UI, business, and even data layers. If you do end up using WF, I highly recommend that you train your general development staff, so that there is broad knowledge and understanding. Despite having a visual aspect to it, WF still requires some low-level coding to build up a library of activities and such that workflow creators and maintainers will use.

EDIT:

Its up to you whether to use it or not. Generally, WF is used by larger projects, because WF offers a valuable return on investment. WF is harder to use than simply writing code. There is a fairly steep learning curve, requires a different way of approaching business problems, and requires special skill sets. Providing code to WF adds overhead, as you have to write activities that may be used in workflows, as well as build the workflows themselves.

If you think that using WF for your small project will provide a valuable return on investment, then go for it. You will need to both recoup the initial costs of training, infrastructural implementation, and deployment, as well as providing long-term, tangible cost savings over simply writing code to solve the problems at hand. I would be doubtful that WF will offer a small project such ROI. For larger projects, or multiple integrated projects for a single large company, it is much easier to realize that ROI than it is with smaller projects, which is why workflow platforms like WF are usually only used on that scale.

Answer 3

WF is mostly understood quite imperatively - a sequence of chronological events.

However, if you delve deeper you can combine activities in different ways. A good example are the state-based workflows that are usually also shown when presenting WF. WF allows you to put the Workflow into an idle mode: It's current state is persisted and reloaded once e.g. an external event takes place. As such, workflows can be useful in tracking long-running interactions where the system has to wait e.g. for some external process to end or some user to interact with the system.

I'd say that WF wouldn't be terribly useful in the UI context. They are better suited as a backend module to express processes integrating several services that have a tendency towards changing in time.

From my point of view, though, it is noticable that WF is a version 1 product: There are a number of awkward things that may guide you into code that is hard to maintain, parts of the infrastructure are quite complex to be used, you may find some API inconsistencies here & there.

There is also a guideline out there what you shouldn't do if you ever want to port your workflows to the next generation of WF.