Dynamically load business logic.

wjcomeaux posted on Tuesday, December 23, 2008

Greeting, happy holidays and Merry Christmas everyone!

Yesterday a co-worker and I were having a discussion about storing business logic outside of the business objects in a way such that others (not necessarily programmers) would be able to edit it. I would like to get some feedback from you all.

The idea as is stands would be to store a record in a database table for each business rule with a structure something like this.

BusinessObjectName, StringForBusinessRule, DescriptionOfRule, LastUpdateDate.

Now, StringForBusinessRule would be something specific to the object at hand so pretend I have an Order_EditableRoot. The DescriptionOfRule would read something like "Is Order Valid For Processing" and the StringForBusinessRule would be something like "if(Order_EditableRoot.Details.Count > 0 && Order_EditableRoot.ToAddress.IsValid && Order_EditableRoot.FromAddress.IsValid".

The idea is that we would load these rules at runtime using something like Spring.Net.

My co-worker sees this as a good thing as it could free the developer from any responsibility when business rules change because then the people changing the rule can affect the program directly.

I see this as a great way to complete disable our servers, put the company at great risk and in general make me have to work nights, weekends and holidays. However, just because I'm opposed to something doesn't mean it's wrong, I just may not fully understand the potential. So, now it's your turn to chime in with pros or cons.

Much appreciated!

Will

rfcdejong replied on Tuesday, December 23, 2008

It all depends if u want to let the business people configure there rules after before or deployment. My guess is after reading your text.

Before deployment:
Just generate rules out of the database, write your own generator to create the (partial class) code. The performance will be significant faster as well.

After deployment:
U can dynamicly add rules in a base class reading the generic type and fetching his own information from another businessobject containing the rules. But ofcourse think about security, i smell a security issue here :)

richardb replied on Tuesday, December 23, 2008

It is a tough one and I've not been able to achieve this and I'm not sure it can be done 100% - on the one hand it seems great idea but might this lead to chaos I wonder?

For example, You might have some business rules that restrict the length of a field. If the user decides to increase it you might need to code changes still in the database to handle the increased column size unless you come up with some clever way of getting around this.

Maybe more relevant is how often do business rules really change? Is your business that dynamic? CSLA helps by having alot of common rules already and you could extend this, so OK if you needed to change them they'd likely be just in once place.

Perhaps worse it this - do you trust your end user (I'm assuming it is your end user) to know what they are doing when they change a rule? Do they really know what the impact can be elsewhere in your systems and business areas?

Would they change things to "bend" the rules and then change them back?

Do you want the user to be responsible for enforcing and applying the business rules or is that your job to build a system that enforces the rules?

Mmmm - I'm trying to think of some Cons honest. :-)

I mean when using XML and XML Schemas to help validate things it's not unreasonable that the same concept might work in some fashion allowing us to describe our rules in XML which we load into the object and use for validation. Not sure that performance would be great though or if it's really practical.

If there was a silver bullet it would be in CSLA.Net already - the CSLA rules validation is very cool now.

I'd be interested to know how you get on. Good luck.

wjcomeaux replied on Tuesday, January 06, 2009

Thanks for the replies and sorry for my delay in responding. Holidays were hectic.

Well, a lot of good points were brought up and to answer a couple.

No, I don't trust the end users, but I'm not the person advocating this approach, I'm actually against it.

The changing of field lengths is not an intended use for these business rules. Those rules are generally derived from the database through code generation. However, as you mention, the possibility exists that someone will write code to do this and we won't know until it breaks.

Also the possibility that someone will abuse the system since we would essentially be giving them access to a compiler with a direct line to a production environment. How hard would it be to write a "business rule" that shells out another executable on the server or does any number of malicious actions.

The only reason this is being considered is because we work in an environment where a product is promised for a date, say January 1, 2009 and it's not until December 31st that some of the business rules are nailed down. In fact, some rules aren't figured out until well after the product is launched; so I have a guy here who wants to empower the end users with this and take the burden off of us. I just happen to think it's a vision of grandeur with tons of potential pitfalls.

I will try to sway him from tis train of thought if at all possible.