Should an ASP.NET masterpage get its data from the view ?

Question

I've been playing around with ASP.NET MVC with a site containing a Master Page.

I created an MVC user control called ProductThumbnailControl. The user control displays a product and a small thumbnail image. The View is a ViewProduct view which displays full product information - the usercontrol just being a UI element off to the site.

 public partial class ProductThumbnailControl :
                      System.Web.Mvc.ViewProductControl<ViewProductsModel>
 {

 }

I read a blog entry that shows how user controls consume ViewData. I learned that the user control can automagically get its model from the parent View. Since it's consuming the same data the View doesn't need to explicitly pass anything to the user control, making for cleaner markup and code.

So now I've learned that the Master Page is using the same ViewData as the page. This means means the Master Page itself doesn't really have a model to help render itself.

Question

Whats the correct way for a Master Page to get its data in the first place?

I thought about trying the following?

You could have a SiteModel :

//Arbitrary properties for example
class SiteModel 
{
    public string PartnerId {get; set;}
    public ShoppingCart ShoppingCartContents {get; set;}    
    public string CurrentUserId {get; set;}
}

The View inherits from it:

class ViewProductModel : SiteModel 
{
    public Product Product {get; set;}
}

SiteModel would be consumed by the Master Page. Views could use data from it if needed - if they needed to display the current user's email somewhere.

Is this a horrible idea?

Should the master page just get its data from wherever it needs it?

What if I want to include a user control in the masthead?

Where would it get its ViewData from since there is only one ViewData object for the whle page?

Would I have to use this horrible syntax that I hate and pass the master page's user control an explicit model?

Html.RenderUserControl("~/Views/Account/UserControls/Header.ascx",
  null, new { SelectedItem = "Profile" })

What's the best way to tackle this scenario?

Answer 1

Our master page takes data from the view. We use strongly typed view names for our views and in the methods for that implementation we also add standard view data that every page needs from our persistent objects (like the application menu structure info, the user info to display on screen and so forth).

This does have the disadvantage of making our view data for the master page not strongly typed like it is for the Model object, but it works very well for us.

Your idea is also good. As the idea of the Master page is similar to the idea of inheritance, why not use inheritance to setup your model objects. You could take it a step further and create a model factory that produces your model objects and sets the base class data while it does so.

Answer 2

Looks like my solution is very similar to Microsoft's recommendation with one key exception. I was creatng a ViewData baseclass, and they create a Controller baseclass - which makes a lot more sense.

However it seems that both ideas could (and should) work in tandem. The MS tutorial below uses a dictionary to store view data, so if you had a strongly typed model you'd also need a baseclass for that.

Microsoft MVC tutorial

Answer 3

I would create a ShoppingCart Controller (or separate controllers for each concern) and render usercontrols that use them with RenderAction found in the Futures DLL that you can download from www.codeplex.com/asp.net. It is part of the ASP.NET MVC source code.

Using a base controller or a 'site model' couples too many things together, creating a testing and maintanence nightmare.