views:

213

answers:

4

In a web application i'm working on, items can pass through multiple states (eg. workflow) and after each workflow a rule can be run after each step which can stop the process or display additional messages.

How should these rules be defined? I was thinking about a dll per rule (and hooking them up either with MEF or events) but one application could have 200-300 customers in it each with a few rules which becomes a lot of dlls.

Update:
These rules could be like the following. Say you submit an invoice but you only want to authorize it from your approver if its over a certain amount, then a rule like this would be invoked to return true or false and then proceed accordingly.

Cheers.

+1  A: 

Sounds like an application that might benefit from using business rules written in a dynamic language like Ruby or Python. IronPython integrates nicely with applications written in C# or VB.NET. You could create a DLR ScriptEngine and ScriptScope in your web application, inject rules written in the dynamic language based on a client ID parameter to interact with your live Plain Old .NET Objects (PONO). You could keep your hundreds of rules in a database because they are just text (Python source code for example). Check out this blog post I wrote which shows how to inject dynamic business rules into a .NET application.

W. Kevin Hazzard
Doesn't feel right.
çağdaş
what does then?
Schotime
@Schotime, without knowing what these "rules" actually are, it's hard to make a guess as to what's the best way to implement them. But I really doubt one would need to combine several languages to achieve this.
çağdaş
True. I was just offering a suggestion. The level of integration between the CLR and the DLR is just marvelous. And with CallSite caching in .NET 4.0, the performance is marvelous. No need to be afraid of Python and Ruby anymore. And writing business rules in Python is a pleasant experience. Again, just offering ideas to Schotime.
W. Kevin Hazzard
A: 

This might be a good candidate for .Net Workflow Foundation

Tom Anderson
A: 

Assuming your workflow engine is database driven, you can distinguish your workflow definition by adding a company id field. You will have to implement this in everywhere workflow is involved, checking what company id it is, and load workflow accordingly. You will also have to create the workflow for each company id separately.

This sounds tedious, but it is actually quite simple and easy to get right.

Then you can further define which user uses which company id. Or if you are certain each user will use different workflow packages, you can use user id instead of the intermediary company id.

Bill Yang
A: 

I have found stuff linked from this post to be an interesting read on multi-customer systems:

http://ayende.com/Blog/archive/2008/08/13/Mutli-Tenancy--multi-tenant-apps-and-frameworks.aspx

Andrey Shchekin