How many modules do you have? Are they hardcoded?

If you’re in a case where you have only ten possible modules which are written once and require the whole update of the entire application if they need to be updated, then you can easily use checks which will propagate through the models and be used by the views to adjust the user interface (for example by showing or not the appropriate links in the web application menu).

If, instead, you’re in a case of many modules developed by many developers and it is unacceptable to require the update of the whole web application in order to update any of those modules, then you should look into plugins model, like for example the one used in FogBugz.

To make a choice, consider the following elements, sorted by importance:

• Maintainability: is it acceptable to modify the common code of the web application in order to change any of the modules?

• Dependencies: are some modules dependent of others?

• Performance: since we don’t know the exact context, it’s difficult to try to predict the impact of each solution. Maybe there will be none, if you use heavy, cleverly designed caching.

• Overall architecture: if there are reasons to do something monolithic (because of the interdependencies), the first solution seems more appropriate; this is not the case if every module is strictly separated from others.

This is actually the reason that frameworks like the Managed Extensibility Framework (MEF) were built.

Using MEF, each optional module resides in its own DLL, and your main program loads the applicable DLLs at runtime. You only need to include the ones for each particular site. You can then have a different user module from one site to the next.

To me the simplest approach would be to set up a permissions table and give each module an identifier. An integer would do and the have some way to identify which site is loaded and check against that table to see if they are set up for it. Where I work now, we do that in the pages since we have multiple users with permissions and multiple countries to contend with. Any one user can have different modules and can use those modules in different countries.

We basically declare a variable on the page and look up the users permissions (that part is done in the master page so we only do it once and save it for the session). Now we need only check the in-memory object to see if they have the permission for that page which is again in a variable.

HTH

OP has answered his own question in a way. In many multi-homed CMS’s, each ‘Site’ has associated ‘Features’. Some features are ‘enabled’. Some require individual settings through ‘featureConfiguration’.

Checks for use, and individual ‘featureConfiguration’ settings, of these ‘features’, because they happen sitewide, only need to happen once: on app startup; thus, can be cached either to disk or to memory as part of the ‘appSettings’. They can be forced to refresh if changes in the settings would invalidate them.

Each controller or page or user control would be adorned with an attribute or property declaring itself as a member of a particular ‘feature’, regardless of what part of that particular piece played. When any piece adorned with a ‘feature’ is requested, simply check if they are enabled, allowed, and configured before continuing to load normally. If not, then redirect when appropriate with notification, or in the case of a control, leave the placeholder blank/empty, or add an abbreviated notification about the unavailable feature that would otherwise be there — depending on what is ideal for that particular piece.

Some parts (controller, page, or control) might be part of multiple features, a ‘shared-feature’. Those would require additional care in determining whether the context and configuration permitted loading.

If the features were dependant on user or role, they would only need to be loaded once per session, and only need to change if during the session the settings changed to again invalidate and require a forced refresh.

Well. All modules are loaded at all times. There is no way around that (if your application is a web app).

Hence you do have to check a flag wether it’s active or not.

If you are using ASP.NET MVC it can be done by using an action filter which you tag each controller with ( + a session variable). something like

[AuthorizeModule(1)] //<-- 1 = module id
public class MyController : Controller
{
}