Data-driven state machine application

Question

We are currently working on a "data-driven" state machine application. Right now, the state flows are all configured in the database, but none of the decision/business logic is configurable in the DB with our current design. Because of this, the code has to basically "know" the state flow as well, so there's really no point in configuring the flow in the database.

I have a design in mind that would allow us to wire together a state pattern using dependency-injection (Spring.NET), but I'm not sure of the best way to make this data-driven. I'm not a big fan of configuring code-like things (like class or method names) in the database, but the design I have in mind would require us to wire up the application in the DB (similar to wiring in a Spring XML file), so that seems bad.

We've investigated using Windows WF, but I think we're a little concerned about the future of WF, and whether this is a good time to adopt it. I've never dealt with rules engines, so I'm wondering if that might be of some use here. Does anyone have any suggestions on how to implement this?

Answer 1

For domain specific language support look here in the MSDN. You may also have a look at Irony but this is probably not yet a solution for productive code.

Answer 2

Your best bet is probably to decouple the data-stored behaviors from the technology used to implement them.

The way to do this is a DSL (domain specific language). Come up with a format that can represent the business logic in the abstract (i.e. a micro language), store strings of that in your tables, and implement an interpreter for it in code. That way, if your underlying technology changes you just have to reimplement the interpreter.

I worked on an application that used this technique in the mid 1980's, and it's been ported several times with only minor (and automatible) changes to the business rules required.