Attention: We have retired the ASP.NET Community Blogs. Learn more >

A master page is not a singleton

Here's a misconception I see a lot on the forums lately. There is this idea that controls on a master page should always keep their state across content pages that use it.
When you navigate away from a page (i.e. when you click a link), you go to another page, with another instance of the controls on it, so of course the new controls on the new page have no way of knowing about the state of the controls on the other page.
Having a master page does *not* mean that all the controls on the master page have a unique instance that would be shared by all pages that use this master page. The master page is nothing more than a template, it's not any kind of singleton.
So the only way you can maintain the state across different pages (whether you use a master or not) is by storing it in Session and using that information when a new page is loaded. This can have severe performance drawbacks as you store state for each user but is more or less what WebParts do with their personalization data...
Another approach is to consider that if you need to maintain state across all those pages, maybe they are the same and you need to move from a many-page model to a single-page model.
Please note that the navigation controls (a.k.a. Menu, TreeView, SiteMapPath) will automatically select the current node in the site map according to the URL you're on, giving a minimum version of this application-level state management some were expecting from master pages.

3 Comments

  • Agreed.



    I have also had arguments with people about whether a master page (from which individual pages are derived) is an implementation of "Page Controller" or "Front Controller". I argue that it is a "Front Controller" since the derived pages act as concrete handlers of the request, but others argue "Page Controller" because the main view-decision code is centralized.



    What do you think?

  • So is there a pro/con list or another thread discussing one approach vs another? i.e. Using the fancy shmancy new master page vs the classic "index.aspx?functionname=" approach? I am working on a new application and I was leaning towards master pages. But I am finding I am missing the functionality and some of the state maintenance of the "index.aspx?function=" approach.

  • Patrick: they are two different things and do not exclude each other. Master pages are meant to provide a simple way to create templated pages and share common layout and/or logic between pages. The command in querystring approach is more suited to implement application logic and flow within one page. You can use both together or one or the other as you see fit. You can also use session when you need to maintain state across pages.

    If you tell me more about your precise scenario, I can comment on it and tell you how I would do it (which would by no means be the "correct" way to do it, just my opinion).

Comments have been disabled for this content.