Declarative or Imperative when designing workflows? RRS feed

  • Question

  • WF offers two programming models when it comes to developing workflows:  XAML based declarative model and pure C# (or other .NET languages) based imperative code.   I consider it similar to the programming models in ASP.NET where you can do code-front/code-behind or pure C# code (as often in custom server control development).  There are cases where one is more appropriate than the other.  I suppose it's the same in WF development.  My question is, what you do you are the situations where the declarative model is more appropriate vs. the imperative model?


    Sunday, August 5, 2007 2:42 AM


  • The primary notion of a workflow for me is the tree of Activities in memory - this is what the WF Runtime executes.  I think of the XAML and the C# (explicitly the designer.cs file) simply as serialized forms of this object tree.  The designer.cs file contains code, generated by the designer, which constructs the Activity tree in memory when executed.  The XAML file contains information which is used to construct the Activity objects and set their properties when it is serialized in.  It is also possible to use serialized forms of your choice by writing a custom Loader - any serialized form is OK as long as the Loader returns a tree of Activity objects.  I don't see any of the serialized forms as more 'declarative' than any other.


    The use of code-behind is an independent question - it may be used with both XAML and designer.cs serializations.  But code is never inlined in the XAML.


    So your choices are 1) the serialized form and 2) whether to use code-behind at all.  The only imperative I can think of that will drive the choices beyond personal preference is if you want to avoid deploying an assembly.  In this case, you need to choose a non-code serialization, like XAML, and also use no code-behind (RuleConditions are the typical alternative)

    Friday, August 10, 2007 10:26 PM