On Thu, Feb 18, 2010 at 3:05 AM, Gerret Hansper
<gerret.public@gmx.de> wrote:
Hi Mike,
I have been working with Drools for only a few months now and am still rather
new to it, but we've have made the same experience, switching from rules only to
rules with flow, and I'm certain it's the right way to go.
The performance implications you mention depend mainly on the way the rules are
set up, I guess.
That is, if you have expensive RHS expressions like eval() you might indeed
profit from keeping your glucose-level condition at the beginning of the rules
which would prevent those expressions from being reevaluted, as far as I
understand.
If you don't I can hardly imagine that activating the rules makes up a
noticeable fraction of the overall time of your process.
We here have a scenario where some rules may be activated only if the user
starting the session has got corresponding privileges.
Since determining the priviliges is not always trivial we definitely wanted to
have that logic in one place. The first thing to do was to use inference
(http://docs.codehaus.org/display/LOGICABYSS/Policy+Encapsulation) but still
already with a few dozen rules and including other constraints the rule RHsides
became rather cluttered. Moreover it was getting increasingly complex to
control the order in which the rules fired, maintanance being another issue.
Using a rule flow we have achieved really good separation of concerns: A rule's
RHS mostly contains exactly those conditions that apply to its intent, none of
the cross-concerns or technicalities. (Hey, what about an AspectDrools
implementation? ;-) )
I am confident that OO lessons apply here, too: If you have a clean design and
performance problems start to show up you are much more likely to solve them
than if you have a tangled web of dependencies.
Greetings,
Gerret