Architecture/Pattern for configurable application (web in my case)

Question

i have already asked this question on asp.net forum, could not find any satisfactory answer. you can visit it to get more details. http://forums.asp.net/t/1420283.aspx

We have a product which can be configured for each client.

The configuration options are UI and Business Logic.

In the UI they can choose to re-arrange all the controls in a given page any way they want it, we hide controls they dont want to see(because those are as per another clients request).

In business logic its a lot of "Switch/Select Case" branches implementing logic as per each client's settings. (I am wondering if i can chose to plugin an external assembly/dll(project built) at runtime depending on the client, which means common code base will call an external code for each client to handle things as per their need.........or maybe just separate the logic of different clients in their own classes)

Right now the UI is completely built at runtime.....which in my opinion(IMO) is not necessary since once configured the UI remains static for the client(except for enhancements which are very few and far between).

But we want to maintain a single code base for easier maitainenance. (atleast the business logic, I am wondering about having different UI for each client, generated from a common template).

I am sure this must have been hundred times for different products...but i never across one and i cannot find anything on the internet.

Answer 1

As far as your business logic, it sounds like you're trying to do some pretty complex things based on user settings. You might want to think about a commercial rules engine to help. One of the one's I've seen used in the past is:

InRule

Answer 2

Look at the Django framework for guidance on this kind of thing.

1. Each client has a separate "application", built from a common set of libraries and components. The client's unique application is an extension of the core application.

2. View Functions do the real work.

   What we do is separate the view functions into two tiers. The top tier is the customer-specific layer, which includes libraries of generic components.

   There are no "Switch/Select Case" branches, since each client's logic is their unique logic. To minimize the effort required to write the client version, we incorporate as much generic logic from the generic component library. We're always moving things that are used by more than one client into the generic libraries and rewriting the client code to simplify it.

3. Templates generate the HTML pages.

   Templates are found on a template search path.

   Each customer can have a different search path so that their customized template directory is searched before the default templates.

What don't have a massive application with lots of if-statements to tailor it. We have a number of small applications that extend a common, generic, baseline application.