Rules engine, pipeline or what?

  • Thread starter Thread starter Andy O'Neill
  • Start date Start date
A

Andy O'Neill

I am designing a system which will work in a totally different way to any
I've designed before.
Almost everything has to be configurable.
The user will be picking things from lists into a basket.
The things have a set of dependency rules.
So you must pick at least so many of one classification.
You may pick no more than so many of another.
You need n of a particular thing per 1 of another.
Unless you pick this special thing which alters how common something else
is.
Then of course they can remove something from their basket.
If that happens to be the special thing that alters rules, then the rules
applied need to revert and give a warning if things in the basket break the
rules.
Things often have a number of options ( optional upgrades ) which may be
chosen and in turn are fairly complex.
EG a given upgrade may only be attached to one thing in the basket.

All these rules need to be configurable via xml or xaml or something.
Even the attributes of each thing will be variable.
It'll be a WPF application with no database - xml will be used to store user
input instead.

Whilst the rules can be quite complex there aren't a huge number of things
go into the basket.

I was wondering if anyone has done anything similar and has any thoughts,
can recommend a pattern... example or whatever.
Thanks in advance.
 
I am designing a system which will work in a totally different way to any
I've designed before.
Almost everything has to be configurable.
The user will be picking things from lists into a basket.
The things have a set of dependency rules.
So you must pick at least so many of one classification.
You may pick no more than so many of another.
You need n of a particular thing per 1 of another.
Unless you pick this special thing which alters how common something else
is.
Then of course they can remove something from their basket.
If that happens to be the special thing that alters rules, then the rules
applied need to revert and give a warning if things in the basket break the
rules.
Things often have a number of options ( optional upgrades ) which may be
chosen and in turn are fairly complex.
EG a given upgrade may only be attached to one thing in the basket.

All these rules need to be configurable via xml or xaml or something.
Even the attributes of each thing will be variable.
It'll be a WPF application with no database - xml will be used to store user
input instead.

Whilst the rules can be quite complex there aren't a huge number of things
go into the basket.

I was wondering if anyone has done anything similar and has any thoughts,
can recommend a pattern... example or whatever.
Thanks in advance.

The only advice I have is to take a look at Windows Workflows. There is a
built in rules engine and you can create and alter rules using a dialect of
xaml.
 
I am designing a system which will work in a totally different way to any
I've designed before.
Almost everything has to be configurable.

Just use enums and make sure they are a power of two. That way you can
XOR them. It's in any standard textbook.

RL
 
I am designing a system which will work in a totally different way to any
I've designed before.
Almost everything has to be configurable.

Just use enums and make sure they are a power of two. That way you can
XOR them. It's in any standard textbook.

RL


By configurable, I mean in separate user maintainable file(s) rather than
code.

Enums have to be written at compile time.
It will be a generic tool.
At the time I write the programme I won't know what to enumerate, let alone
what values mean what and what rules to apply.
 
I was wondering if anyone has done anything similar and has any
thoughts, can recommend a pattern... example or whatever.

I like the workflow option and would advise at least looking it over. It
might not work for you, but it will greatly reduce the amount of
plumbing you need to write.

If that is not an option, the direction you head depends on what the
items on the list are. If primarily behaviors, then I see a couple of
patterns coming to mind:

1. Decorator - to add "rules" into the workflow
2. Strategy - to better switch out algorithms

This is a very high level look and I understand too little about your
project to be more specific.

Another possible pattern is the chain of repsonsibility, if you can
easily chain the workflow together

If you are heading with state, decorator is likely to still be involved.

Just some thoughts off the top of my head.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
The only advice I have is to take a look at Windows Workflows. There is a
built in rules engine and you can create and alter rules using a dialect
of
xaml.

Thanks Tom, that's a great idea.
I briefly considered WWF but didn't realise the rules could be xaml.
 
Gregory A. Beamer said:
I like the workflow option and would advise at least looking it over. It
might not work for you, but it will greatly reduce the amount of
plumbing you need to write.

If that is not an option, the direction you head depends on what the
items on the list are. If primarily behaviors, then I see a couple of
patterns coming to mind:

1. Decorator - to add "rules" into the workflow
2. Strategy - to better switch out algorithms

This is a very high level look and I understand too little about your
project to be more specific.

Another possible pattern is the chain of repsonsibility, if you can
easily chain the workflow together

If you are heading with state, decorator is likely to still be involved.

Just some thoughts off the top of my head.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

Thanks.

I'm a LONG way outside the box here.
My box amyhow.
Usually I have a database and concrete classes with a known list of
variables and just one set of business rules.

I think the workflow approach is probably the best candidate.
Failing that, there are open source rules engines to look at.
As you say, writing all the plumbing that attaches rules could be very time
consuming.
I initially had in mind something based on the pipeline approach I've seen
used with linq.
So the selection rules would be read from xml and into a collection which is
then used in the selection pipeline.
I then thought about driving events from that and realised the scope of the
design.


I didn't explain what the package is for because it's somewhat esoteric and
I thought it probably wouldn't help other than convince readers everything
must be configurable.
 
Back
Top