How should I write flow-chart-like code? Or should I use something like Windows Workflow Foundation?

I'm investigating the how best to develop/code a flow-chart like scenario.

For example, given the following diagram I could write the pseudo-code beneath it to satisy the requirements. However, as the flow chart changes, this would become difficult to maintain. Also, there's a fair amount of duplication which, again, would only get worse when the flow-chart becomes more complex.

Is the problem I'm trying to solve exactly what Windows Workflow foundation is for? Or would that be too heavy-handed an approach for the task at hand?

Perhaps there is an obvious solution I'm overlooking? Thanks for your help!

(P.S. I should mention that I'm looking for a .NET based solution)

..and the pseudo code...

Public Function Inbox() as Result

    If IsItImportant() Then
        If IsItUrgent() Then
            If IsItBestUseOfMyTime() Then
                If WillItTakeMoreThan15Mins() Then
                    Return Result.ProjectList
                Else
                    If CanDoItNow() Then
              开发者_开发百科          Return Result.Now
                    Else
                        If DoesItHaveDeadline() Then
                            Return Result.Calendar
                        Else
                            Return Result.NextAction
                        End If
                    End If
                End If
            Else
                Return Result.Delegate
            End If
        Else
            If IsItActionable() Then
                If IsItBestUseOfMyTime() Then
                    If WillItTakeMoreThan15Mins() Then
                        Return Result.ProjectList
                    Else
                        If CanDoItNow() Then
                            Return Result.Now
                        Else
                            If DoesItHaveDeadline() Then
                                Return Result.Calendar
                            Else
                                Return Result.NextAction
                            End If
                        End If
                    End If
                Else
                    Return Result.Delegate
                End If
            Else
                If IsItReferenceMaterial() Then
                    Return Result.File
                Else
                    Return Result.Trash
                End If
            End If
        End If
    Else
        If IsItWant() Then
            Return Result.Someday
        Else
            Return Result.Trash
        End If
    End If

End Function

This does seem like a very good fit for WF4. WF4 is much lighter than you'd expect. I've got relatively complex workflows containing custom activities that execute in milliseconds. Also, its very easy to create custom activities that make creating workflows easier. And the design surface being WPF makes creating custom designers a breeze.

Workflow Foundation is meant for long running processes (days, weeks, months) that may "go to sleep" on one computer and "wake up" on another. An example is a trouble-ticket system, where the workflow begins on the workstation of the person reporting the problem, may "wake up" inside a server somewhere that decides which department handles it, wakes up again in that department's system and could be further processed by managers, QA departments, billing departments and so-on.

Without more details about your problem, what you're looking for doesn't sound like what WWF is designed for, and if you were to try using WWF you'd probably end up with a system much too complex to maintain.

The problem of writing code in such a way that it remains maintainable is an old one, and it's what most of the CS buzzwords are trying to solve: Top-Down Programming, Object Oriented Programming, CASE, UML, Dependency Injection and so-on.

In your case, it may be that you just need a combination of Top-Down Programming (begin with your flowchart, then write it as pseudocode, then convert that into runnable code) plus Refactoring.

In other words, write it the first way that comes to you, then revisit the code to look for opportunities to improve it, consolidate duplicated code into abstractions and libraries, delete orphaned code, etc. Regular refactoring can keep a codebase in a form that's easy to maintain, without needing a big abstraction like WWF and all the complexities they bring with them.

I'm not sure WF is right tool for this job. What I don't see in your description of the problem is a need for integration between modules and systems. That's where the sweet spot for using WF is, trying to harness together different external systems to attack a single process (the "Workflow/Flow-Chart") in an organized and monitorable fashion, allowing visibility into the current state of the process and being able to "stay alive" awaiting the external systems responses in a non-blocking fashion. I'm just not sure that what is being described is worth the overhead that WF would bring.