RSS

Windows Workflow Foundation Episode 2

30 Nov

[Yes – I know I only published episode 1 a few minutes ago, but I wrote these 2 posts on a 14 hour plane trip]

Welcome back to WF4 for K2 developers. In my earlier post I spoke about the differences between K2 and WF4. In this post I’ll speak about the workflow designer options you have and some best practices.

There are a number of ways you can build your workflows, each with pros and cons

  1. Firstly there’s the graphical designer. All you K2 gurus will leap straight into this one, but keep in mind that there are no line rules – you have to use decision points to build in your business logic. Also, there are several options for the graphical designer – you could use a sequence, a flow chart, a state machine, or any combination of these. Again, each of these have their pros and cons, but if you’re looking for something similar to the K2 canvas then try a flow chart. True to style, the graphical designer is purely a front end to generate XAML, which leads me to the second option…
  2. XAML. If you’re happy coding in XAML then you can do it all in XAML. Personally I don’t see the point…
  3. Code. Anything you can do from the designer you can do in code, and I have to say that it’s very well thought out – designing a workflow in code is simple, quick and easy to follow (to a point).

So which should you use? The answer is, of course, that it depends on the workflow you’re designing. Here are some guidelines which should help you choose…

  • For small workflows, use code. There is a VERY tiny performance improvement, it’s easy to edit the functionality, but the biggest advantage is the ability to use the built-in refactoring functionality. If you’re using XAML or the designer, you’re refactoring manually. Of course if your workflow is coded then you can step through it in the debugger as well.
  • For all other workflows, use the visual designer. As nice as the code is, it quickly becomes difficult to follow the business logic and you get lost in a sea of confusion.
  • For those of you in the real world, you will use both. When I am building a WF4 app I create a project to hold commonly-used custom activities which I have written. Some of these are in code, some are in XAML, but when I build the actual workflow it’s always in the designer. The only thing I would say is that there’s no point in writing a workflow in XAML from scratch. It’s like coding C# in notepad. Yes, you can do it, but why would you?
  • We have an approach in Dynamyx which is “everything is a framework”. Try make your approach to your workflows as generic as possible. Look for reusable sections and turn those into separate custom activities. Build up a library of generic activities for use in other projects. When we start building our workflow engine you’ll see what I mean.

Finally, if you’re using code activities you will be writing classes which will inherit from one of several base classes. By default you should either use CodeActivity or it’s asynchronous counterpart since these are lightweight. If you need more advanced features (like automatic persistence when your activity is idle) then you need to inherit from NativeActivity. There are others, but these cover 99% of the cases you will see.

In the next post I’ll speak about workflow persistence and events since we’ll need a good understanding of how this works before we you can dive into developing the workflow engine.

 
Leave a comment

Posted by on November 30, 2011 in Windows Workflow Foundation

 

Leave a Reply

Your email address will not be published. Required fields are marked *