Should you code your business logic or use a workflow model?

Found this interesting article from Paul Andrew from when he was the product manager for Windows Workflow Foundation and Windows Communication Foundation.

He has since moved into the SharePoint product team – his title is now “Microsoft Technical Product Manager for the SharePoint Developer Platform”.

Great to have a WF-oriented person within the SharePoint world.

Workflow development is a natural progression from writing code. But many developers are uncertain about when to use a workflow runtime instead of just writing code for business logic.

It’s a good question because it’s possible to develop all of your business logic in code.

However, using a workflow runtime offers some major benefits in certain scenarios.

This article applies directly to Windows Workflow Foundation (WF), but there are many aspects that are true for workflow implemented using “K2” – as much as for WF. 

The reasoning is still the same – with obvious differences in the technical implementation – the article essentially highlights that the workflow approach is a better way to go.

(P.S.  You don’t have to write ANY code if you use K2 – instead of WF !)

Here are some of the decision “criteria” from the article (code vs workflow) :

  • long-running business logic ?
  • business logic or business rules of process change frequently ?
  • needing visibility into business-logic for non-developers ?

Fairly brief article – worth a quick read – some good points.  

Source : Redmond Developer News (June 2007)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s