This is the first in the series of blog posts that will attempt to cover what was missed from my not being able to talk at DDD Scotland 2011.
In this first post, I want to do nothing more than touch on declarative and imperative programming and why this is important when we look at Windows Workflow. It is aimed at nothing more than to set the scene for the posts which are to follow.
As developers, we are all aware of the fundamental difference between declarative programming and imperative programming. At it’s simplest, declarative programming is when we say what we want to do, against imperative which is us saying how we actually want to do it.
But why is this important when we are working with Windows Workflow 4?
Windows Workflow 4 provides us with a completely declarative programming framework which is clean and simple enough to allow us to model out business processes. The Windows Workflow programming model provides us with such an environment which fully allows declarative composition of activities which have no code-behind files which greatly simplifies the authoring of each workflow. At this point, I’d like to highlight that this doesn’t mean that we never write code. We still do write code for the implementation of each activity. (We will look at this in a later post.)
It is important to consider that when working with Windows Workflow, that we aren’t actually writing applications in the traditional sense. More so, we are composing applications from pre-defined re-useable assets/activities into a particular structure or flow which ultimately speeds up development whilst hopefully improving the maintainability of our code.
In addition, this declarative programming model provides us with additional semantics for transactional and compensatory tasks. Basically, when things go wrong, we are given the ability to compensate by coming back to the task in hand, or taking some other action. This is something which is not readily available in other .NET or imperative languages.
As developers, all of this makes our lives easier. When we are using imperative techniques, we can, eventually, figure out what is going on by following the path of execution within the code, through different method calls and no doubt with the debugger attached. With the declarative technique however, we have that model that self describes and as such is very easy to look at and figure out what is going on. This doesn’t only help us as developers but will also help wider members of your teams, such as business analysts who also need to know what is going on.
