Designing an ASP.NET MVC 3 Site to Support Customization of the Client Without Branching

Question

I am working on a large ASP.NET MVC site, a commercial service sold to customers. We sell mainly to small and large institutions so that they do not shrink. These large customers will ask us to make settings, mostly wider than, but including customizing the layout according to their site.

Our current thinking is that even with MVC its natural conclusions followed with the help of very simple controllers that only call different code (as recommended), looks will be a difficult problem, because they do not lend themselves to this type in any case not with Razor, as we used. It is difficult to subclass them and say "for this client, do something a little extra"; especially, it’s hard to serve slightly different HTML for the same design.

We cannot understand how to make work with several tenants and individual tenants work cleanly, and we do not want to deploy a code base, even if the settings for one or more clients are exhaustive. (As much as possible, we want to keep the database structure isomorphic for all our customers, which, I think, is how we do it for multi-tenancy, but each tenant must have its own IIS website because of the size and isolation. ) Even if we came up with a way to overlay the layer of user views, this would provide the possibility of minor logical inconsistencies in the views.

What is the current state of affairs? What are war stories? (This may be subjective, but basically objective is that if there is a template or approach that completely reduces it to its essence, of course, the correct answer. And I think this is an interesting question.)

I am pleased to provide more details.

Answer 1

We recently created a site to support our 5 Regents institutions. Since we have a fixed set of customers that is unlikely to grow, we made some options that you cannot make. For example, we have a separate database instance for each client. Obviously, this does not scale very well, but it greatly simplifies the model, so it works for us.

The strategies I used are:

• Focus on features and configurations, not clients. We have a set of core functions for each institution. Only some of these features are customizable. For each institution, we support the Web.Config transformation, which contains their selection for custom functions. The publish option is used to control which conversion is used when publishing this application. View / controller uses the configuration data to implement a variant of the function specified for this institution. He does not know which institution this is happening in, just in the configuration it says: “Do A, not B, when rendering widget C”.

• Divide topics into common and nodal components. Most CSS / images are common to all institutions, however we load CSS for the site, allowing us to redefine a specific site. These are mainly colors, backgrounds and images specific to the institution (banners, etc.). We place theme themes in separate folders within content/themes . The configuration item is used to set the theme folder, and master views pull out this configuration item when building the URL for CSS and any images related to a particular site (most, if not all, of them are processed in the site’s CSS file itself).

• Supports a strongly typed configuration class that wraps a standard configuration. Add this class to controllers, mailers, etc., where configuration is needed. Because we rely on configuration through the app, we felt that moving this to a first-class organization in our model was important for readability and maintenance. For non-binary parameters, we usually create enums that map to this parameter to avoid string comparisons. For a more complex application or more institutions, I probably even developed a separate configuration section handler and would split the configuration into my own section or configuration file. At the moment, ours uses appsettings , since the number of settings is small, and they are relatively simple.

Hope this helps.

Answer 2

It looks like you want to take a look at multiplayer views, there was a good article on this subject by Rob Ashton some time ago .