Take the 2-minute tour ×

I am trying to run multiple sites using single code base and code base consist of the following module (i.e. classes)

  • User module
  • Q & A module
  • Faq module

and each class works on MVC pattern i.e. it consist of

  • Entity class
  • Helper class (i.e. static class)
  • View (i.e. pages and controls)

and let's say I have 2 sites site1.com and site2.com. And I am trying to achieve following functionality

  • site1.com can have User, Q & A and Faq module up and running
  • site2.com can have User and Q & A module live while Faq module is switched off but it can be turned-on if needed, so my query here is what is the best way to achieve such functionality

Do I introduce a flag bit that I check on every page and control belonging to that module? It's more like CMS where you can turn on/off different features. I am trying to get my head around it, please provide me with an example or point out if I am taking the wrong approach.

share|improve this question
It looks to me like you want to learn about Dependency injection. The .Net framework Managed Extensibility Framework is linked from there and might be just what you need. –  Mark Booth Oct 19 '12 at 13:40
what platform are you developing for? is it a wep app with asp.net mvc? –  k3b Oct 22 '12 at 13:51
add comment

5 Answers

up vote 7 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.


share|improve this answer
add comment

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.

share|improve this answer
add comment

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
share|improve this answer
add comment

Your Answer


