Dynamic business rules in a web application

Hello!

The work on the web project was that business rules and logic should be customizable by the client. I want to do this without having to recompile the application every time we register a new client in the system. So far, I have described the following architectures:

  • Windows Workflow: Create dynamic workflows and save them to a database.
  • Reflection: Create a business rule interface and use reflection to load a custom client assembly.
  • The true business rule engine
  • IOC container implementation as a structure. [zaff: added 6/4]

Have you ever implemented something similar? If so, what is your experience? And finally, is there another solution I have to explore?

Thanks for the help!

+7
c # inversion-of-control business-logic workflow-foundation
source share
6 answers

I used most of the approaches you mentioned. The answer may depend on many factors.

What roles of the client will make changes to the business rules (for example, business analyst, developer, experienced user, etc.)? Significant support for business analysts may require the creation of a rule engine with external rules in db and the user interface used. Significant developer support can be as simple as using something like MEF ( http://www.codeplex.com/MEF ).

You can also specify how often business rules need to be changed and what types of related operational requirements may apply (for example, the host process must remain on, unload the application domain, etc.). A good choice may require some careful assessment of likely or unlikely future needs.

+2
source share

You can implement data-driven business rules such as this . Decision trees can also be a good way.

You can also think of aspect-oriented programming as a way to implement business rules.

My only caveat with the Rete induction rule mechanism is that rule sets should be small and close to the objects that use them. If you can encapsulate the behavior of an object in the rules engine, then part of its state is better. I don’t care about a “corporate” solution that dumps thousands of rules into a singleton rule engine that becomes dependent on every part of the enterprise.

+2
source share

This may not be the best approach, but my company has successfully implemented your option number 2 in several cases.

Basically, we will configure clients in a database or configuration file, and for each client there will be a lookup table in which the class name will be stored to call any business operation. When the code receives a request for client A, it searches for a class to use and creates it and executes it through reflection.

I'm not a big fan of creating code-related things in a database, but it really works fine and in this case is not too complicated.

+1
source share

I suggest a combination of 1 and 3.

But do not store the workflow in the database, store it in the decision tree or in the rule stream (as we call them).

Changing the workflow to host a specific client or merging it into their profile is a simple task when you have a visual tool that is controlled by actions, such as Visual Rules . There is also the great benefit of having your business analyst or support specialist make this change without having to adjust the code.

None of these requirements also require sophisticated AI tools such as RETE and inferencing. It is best to use consistent logic.

+1
source share

I like WF, but if you looked at it and decided that you want something else, you should look at K2 . In addition, BizTalk supports BRE.

0
source share

I created a dynamic rule engine based on the following open .NET Engine Rule Engine NxBRE . I used the Flow engine as a basic example for my dynamic rule engine.

I used the same architecture as in your question.

0
source share

All Articles