I recently blogged about how I like the idea of simple workflows. Ones that can be written and integrated in a few minutes.

I want to make prolific use of workflows in my apps, and for that I need as little resistance as possible. Minimal code, minimal tooling, and minimal infrastructure.

I'm having a crack at solving this, for some deranged sense of fun :)

Problem No. 1 was designing and defining workflows. I don't want to have to use a graphical tool, DSL nor XML files. DSLs need learning, graphical tools slow you down, and XML is clumsy.

So, why not defining workflows in C# or VB.NET? By this I mean using C# as the DSL, not as an object model. After some juggling, I got some code like this. It defines a workflow for online registration.

public class NotRegistered : State
{
    public Confirming RegistrationSubmitted { get; set; }
}

public class Confirming : State
{
    public Registered ConfirmationReceived { get; set; }
    public Deleted After14Days { get; set; }
    public void SendConfirmationEmail(){}
    public Confirming After2Days_SendReminder { get; set; }
    public Deleted CacellationReceived { get; set; }
}

public class Registered :State
{
    public void ActivateUser(){}
}

public class Deleted : State
{
    public void AuditAndDelete(){}
}

This looks quite neat when viewed in a Visual Studio class diagram. Those 22 lines of C# code make a diagram like this:

As you can see, we have states, transitions, triggers, entry activities and trigger activities. No guard clauses yet, but they're on the way.

So that's the workflow defined in very little code. But, it doesn't do anything. It's just a definition.

Next blog post I'll focus on other aspects I've got working, including:

• Integrating the above workflow into the ASP.NET MVC default registration process in about 5 lines of code.
• Writing a simple workflow engine to parse the definitions (fluent API included).
  
• Persisting the workflows with NHibernate (in about 10 lines of XML)
• Handling time-based triggers.