Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

Andreas Öhlund — Tue, 06 Mar 2007 21:57:03 GMT

I agree that a rules engine is a bad idea most of the time but what about the scenario where you have a lot of complex business descisions that frequently must be modified by "business users" i.e the rules need a tight edit/test/deployment-cycle separated from your supporting IT-systems? (eg. rules for credit assessment, incurance policies etc.)

I guess those cases are rare but I can see some use of a BRMS in the above examples.

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

NickMalik — Wed, 07 Mar 2007 08:30:27 GMT

Hi Andreas,

Even then, consider this. If I have an insurance policy system, I want to be able to configure some fairly complex rules. With some Commonality - Variability Analysis (CVA), you can usually distill out a set of numeric values or a table that drives the logic. You write the component that consumes the data, and you put the data in a database.

You still want to have your app use configuration data to select in the component, but for over 80% of the changes, data changes are all you actually need. If your logic changes enough to need to change the code, then you WANT a longer test cycle.

As I said in the post itself, there are probably narrow cases for a component that is more general. However, for over 95% of the applications, a rules engine is just not an effective way to spend your money.

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

Kevin I — Wed, 07 Mar 2007 18:43:58 GMT

I agree with what you're saying, as I have recently had that issue with integrating rules in a frontend (driving user control validation) and backend (validating data before saving).

Current rule engine generators do not address this, but I think with the enterprise library attacking business rules, hopefully we might see more integration of the tiers and common rules.

We ended up making our own rule validation engine where we create one ruleset and it can be used in the backend, or front end. If in the frontend, then any controls bound to data which is associated with rules are automatically affected and display validation of one or multiple rules.

And we can create a ruleset with rules that a ui wants, and have a backend use those rules and create additional ones that are only relevant for the backend.

So I do not necessarily think rule engines are bad - just that they are currently not thought out very well for different tiers.

New and Notable 148

Sam Gentile — Wed, 07 Mar 2007 20:11:04 GMT

Still real tired from my Oklahoma trip , partying with Raymond sure is exhausting-). Agile/Development

Rules Engines v.s. Dependency Injection

Trumpi's Blog — Wed, 07 Mar 2007 23:21:55 GMT

It appears that Nick Malik is out to motivate that rules engines are not as useful as dependency injection.

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

Ernst Kuschke (C# MVP) — Thu, 08 Mar 2007 12:10:31 GMT

Couldn't this idea, though it doesn't conform to traditional "rules engine" ideas, just be called a new rules engine? :P

How about a hybrid? I see a UI where business users edit business concepts, ie. change values etc., these are persisted (wherever - xml / db / etc) and your strategy-classes can be hydrated from this persisted data and passed on to the execution engine.

Rules engines and dependancy injection - a response to Nick Malik

Charles Young — Sat, 10 Mar 2007 02:52:56 GMT

Nick Malik published a thought-provoking article on rules engines recently. You can read...

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

Charles Young — Sat, 10 Mar 2007 02:59:37 GMT

Nick, thanks for a really interesting article. However, I strongly disagree. In reality, many modern rules engines offer an excellent platform for implementing rules using dependency injection patterns. There is no 'battle', therefore, between the two approaches. There is, however, a marked degree of ignorance about what rules engines offer. I've written up my thoughts and posted them at http://geekswithblogs.net/cyoung/articles/108411.aspx.

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

NickMalik — Sat, 10 Mar 2007 08:40:15 GMT

Hi Charles,

I read your blog reply and attempted to add the following text as a comment, but unfortunately, the blog software gave me an exception message. So I'm posting it here. I hope you see it.

Wow. I take it as a compliment that you took the time to offer such a lucid and detailed counterpoint to my post. I respect your opinion and I'm glad you shared it. (as you probably guessed, I'm not swayed by your arguments, but I am impressed with amount of detail and considerable knowledge of your field you offer.)

Thanks,

-- Nick

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

jamet123 — Tue, 20 Mar 2007 19:51:18 GMT

Interesting post though I think you miss the point on rules. It is not (mostly) about executing the rules but about managing and evolving them. That's where business rules management systems (which include a rules engine) shine and outperform any pattern that involves writing a bunch of code ;-)

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

shige — Wed, 21 Mar 2007 05:52:59 GMT

sorry to interrupt.very curious topic! I'm an application developer and confused a little. Nick is talking about just Rule Engine,right? jamet123 is talking about BRMS,isn't it? I just have thought that dependency injection and Rule Engine help each other on the application code, by the way.

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

NickMalik — Fri, 23 Mar 2007 10:27:03 GMT

Hi JT,

I believe that my post mentioned the "point" of isolating the rules so that they can be managed. I believe I also made the "point" that only a small subset of the actual rules CAN effectively be encoded in a rules engine. That means that some rules are still in the "bunch of code," reducing the effectiveness of the whole rules-engine concept.

Of the 20% of the rules that an engine can handle, then a BRMS is useful. For the other 80%, it's useless.

However, when you decide to embed a rules engine in an application, you increase the cost to the application, and decrease the performance, efficiency and maintainability dramatically. Those are prices that you pay to do what... maintain a subset of the rules?

The price is high and the benefit is low. QED

re: Perhaps it is time to declare victory in the battle of Rules Engines vs. Dependency Injection

NickMalik — Fri, 23 Mar 2007 10:34:54 GMT

To Shige and Ernst,

Thank you for your thoughtful responses. Yes, injection is often used inside rules engines, and they are not incompatible.

The point I was trying to make is that any situation that forces you to go out of process to execute the rules is counterproductive. A framework, on the other hand, that runs in process with the app, that allows injection of modules that implement rules, that is fine. A framework inside the rules engine, even if it allows injection of an execution module, is still outside the process boundaries.

Frameworks are fine. It is cool if some of the "out of the box" functionality in that framework is the ability to execute scripted rules or generic rules, because (a) the value of the engine is not in the generic execution but in the injection framework, and (b) you can execute the rules in the location in the code where it is needed without having to package up the current system state and pass it out of process for evaluation.

I've seen rules engines work... when the application is written in the rules engine environment itself. In that case, you have the rules running in process with the app. It is the parallel to my concept. If you can't take the mountain to the man, take the man to the mountain.

New and Notable 148

Sam Gentile's Blog — Wed, 03 Dec 2008 18:10:00 GMT

Still real tired from my Oklahoma trip , partying with Raymond sure is exhausting-). Agile/Development Tools On my short list for some time now, is to switch from NUnit to the definitely superior MbUnit. My friend Andrew has done some great work with