Rules engine, pipeline or what?
in [CSharp]
|
Prev: NetworkInformationException in NetworkInterface.GetAllNetworkInterfaces thrown when running as windows service
Next: Bug in RegistryKey.SetValue
From: Andy O'Neill on 4 Jan 2010 10:17 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.
From: Tom Shelton on 4 Jan 2010 10:32 On 2010-01-04, Andy O'Neill <aon14nocannedmeat(a)lycos.co.uk> wrote: > 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. -- Tom Shelton
From: RayLopez99 on 4 Jan 2010 12:27 On Jan 4, 10:17 am, "Andy O'Neill" <aon14nocannedm...(a)lycos.co.uk> wrote: > 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
From: Andy O'Neill on 4 Jan 2010 13:24 "RayLopez99" <raylopez88(a)gmail.com> wrote in message news:059ff5c5-fab2-4973-baaf-568ab709f880(a)k17g2000yqh.googlegroups.com... On Jan 4, 10:17 am, "Andy O'Neill" <aon14nocannedm...(a)lycos.co.uk> wrote: > 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.
From: Gregory A. Beamer on 4 Jan 2010 14:41
"Andy O'Neill" <aon14nocannedmeat(a)lycos.co.uk> wrote in news:EEn0n.36533$Ic5.30388(a)newsfe16.ams2: > 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! | ******************************************* |