Design pattern to invoke different business rules on presented UI elements

I am working on a project that is developing a website application for 3 clients. All clients are happy with the base product that we are producing. 2 of them have some slightly different requirements - about the visibility of certain controls, different data binding to dropdowns, etc.

My question is - knowing that each of the 3 clients will keep coming with their own specific requirements, what is the best way of implementing these requirements at the UI??

I do not like the idea of having a series of IF-statements in each web form that I have that goes and manipulates drop-downs and control visibility individually. It simply litters my nicely organised files with custom requirements.

Can someone point me to a pattern(s) that could fit the bill?

Have a look at this simplified hypothetical example to see what I am talking about:

• A web form is populated with a drop-down that has 3 menu items (e.g. Home number, Business number, Overseas number); the drop-down is used to record a phone number type to a contact

• 2 of my clients, are happy to associate as many phone types to a开发者_StackOverflow中文版 contact (even if duplicates can occur)

• 1 client would like us to only show 'Home number' and 'Overseas number' in the dropdown if the current contact has already associated a 'business number' to his profile

I am thinking that I could possibly throw a notification event that contains the dropdown instance and a unique name for it. And then i have different 'client listeners' that consume these events and modify the controls that they get passed in separate classes - hence each client configuration is kept in nice clean silos.

I'd say you need to use State pattern, but it could be many other ways.

You don't really say what technology you're using. I will assume ASP.NET. If that's not the case, please update your question to include technology, as it can make a huge difference in what kind of solutions are possible.

You basically have two main approaches to this. You can create an abstraction layer for each and every control in your UI that validates itself against a set of rules. This is the most flexible, but it means you are adding the overhead of abstraction to every control, whether it needs it or not... and most likely, 95% of your controls won't need it, thus added overhead.

The other option is to require each page to run through various extra steps, probably by creating your own "OnXXX" events (OnOurCompanyPreInit, OnOurCompanyInit, etc..) in which you place extra logic for each client.

One of the drawbacks of frameworks like ASP.NET is that in it's quest to be highly flexible, it enforces a certain seperation of concerns that may not line up with the seperation of concerns you need.

The following method is what i used on my project to do configuration specific changes for different clients.

The ASP.Net project is developed in a modular, common base that all clients get.

After the Page is populated with appropriate Controls and just before we start rendering, I pass the Page object to a module that does all the client specific configuration changes.

So in the base call of my page, I have something like this:

protected void Page_Load(object sender, EventArgs e)
{
    PreRender += ConfigurationInterceptors;
}

The ConfigurationInterceptors method will pass the current Page object to a module that will read the client specific configuration, loop through the controls it needs to be modify, and modifies at runtime and before being server to the client webpage.

protected void ConfigurationInterceptors(object sender, EventArgs e)
{
    Interceptor interceptor = new Interceptor(this.Page);
}

The Interceptor class is then a standalone tier that runs a series of FindControl calls and modify as required.

In this way, this pattern has managed to allow us to put client specific customizations in a separate silo and not complicate the base common code base.