In asp.net-mvc, how can I refactor my site.master page to support 2 different master views?

Question

I have a team asp.net-mvc website and in the site.master page I have

• a header image
• a menu
• all my js and css includes.

I now need to use the site for two different teams where I run the site on two different ports and each team only see's their team's info (pretty much same exact site and same db but just different database filters)

I achieved the backend by adding this to my controller class:

     string team = ConfigurationManager.AppSettings["Team"]

and based on that value, it changes the DB queries i run. That is working great but now I need to do some tweaking on the frontend (as i realized the header image and some menu items need to change as well)

Given that, I now need to refactor the site.master as i need to use the same codebase to support the view for two different teams and I want

• Each team to show its own headerImage
• Each team to have its own menu items
• Avoid duplicating any common code (like css an js includes)

(which are now just hardcoded in the site.master file)

I could copy and paste all of the code into a different master page (lets say site2.master) and duplicate all of the common code but I wanted to see if there was the ability to factor out all of the common code between the 2 master files to avoid duplication.

Also, i am trying to figure out how i can have my code dynamically "figure out" which master file to use based on a config entry. I was thinking about using nested master pages but that doesn't seem to work because each page really is applicable to both Team1 and Team2 and just needs to get set dynamically. I hopefully want to avoid a situation where I have this switch code on EVERY controller action

Answer 1

Since you will have different menu items (this is the major part of what you said that is determining my answer), I believe that two master views would be the better approach rather than having either:

a) a If/Else in your master view or

b) a ton of configuration entries that you would have to parse on each request, and

c) Provides an easier path for more custom theme-ing in the future if so requested or needed.

But, there are definitely ways to reduce the amount of code that you need to write and avoid duplication. Below are some suggestions that I would recommend

1.Use the same logic as you do with your DB query settings to set the master page depending on the team. Example:

<appSettings>
   <add key="team" value = "WhateverYouAlreadyHave"/>
   <add key="layout" value = "~/Views/Shared/team.master"/>
</appSettings>

2.In your views, specify your layout view in the top portion as so:

@{
    ViewBag.Title = "My Page Title";
    Layout = @ConfigurationManager.AppSettings("layout");
}

3.In your master views, factor our the JS and CSS into a shared partial view that you can call from the master pages

@{Html.RenderPartial("HeadContent");}

I believe that this achieves your goals of not repeating yourself in your layout information as well as cuts down the potential need of If/Else statements in your master views. Lastly, if you ever had to separate out the sites (different servers or something) you should be able to do that quickly without having dead code floating around your views.

Lastly, I suppose an alternative solution would be to keep a single layout file, but reverse what goes into the shared partial view. Meaning you could store the header image as a configuration value as well as the shared partial view name. In this instance, put your menus in their own partial view that you could call from a single master. However, if you really wanted to provide custom layout/look/theme in the future, this would be more problematic to achieve with a single master page.