Idiomatic way to communicate state from derived page in MVC?

Question

I have navbar elements in my _Layout.cshtml which depend on the controller being called. On a search page there will be no navigation but in order to keep the style of the site consistent the navbar itself will remain. I'm not sure what is the most accepted and idiomatic way of performing this work.

_Layout.cshtml

 (etc)
    <nav>
        <div class="container">
            <ul>
                @if (TempData.ContainsKey(KeyChain.ItemKeyTempDataKey))**
                {
                    var itemKey = TempData[KeyChain.ItemKeyTempDataKey] as ItemKey;
                    <li>@Html.ActionLink("Overview", "Index", "Overview", itemKey, new { })</li>
                    <li>@Html.ActionLink("Purchasing", "Index", "InvoiceMovementHistory", itemKey, new { })</li>
                    <li>@Html.ActionLink("Profit Trends", "Index", "SalesMovement", itemKey, new { })</li>
                    <li>@Html.ActionLink("Coupons", "Index", "Coupon", itemKey, new { })</li>
                    <li>@Html.ActionLink("Deals", "Index", "WebDeal", itemKey, new { })</li>
                    <li>@Html.ActionLink("Update Log", "Index", "UpdateLog", itemKey, new { })</li>

                }
            </ul>
        </div>
    </nav>
 (etc)

ItemKey.cs

public class ItemKey
{
    public string Upc { get; set; }
    public string VendorItemCode { get; set; }
    public int Vendor { get; set; }
}

UpdateLogViewModel.cs

public class UpdateLogViewModel
{
    public IEnumerable<UpdateLogEntryViewModel> UpdateLogEntries { get; set; }
}

UpdateLogController.cs

    public ActionResult Index(ItemKey itemKey)
    {
        TempData[KeyChain.ItemKeyTempDataKey] = itemKey;
        //etc uses itemkey to get data in order to generate updateLogViewModel
        return updateLogViewModel();
    }

Things I thought of

1. Using TempData (as above) to display the navbar elements if the itemkey is populated. TempData, however, is kind of on its way out and feels hacky.

2. Add a rendersection to the navbar, put the navbar elements in a renderaction and populating them in the section on every view that uses it (which is essentially every view EXCEPT the search view). This just violates DRY on overdrive, but seems to me to be the idiomatic thing.

3. Derive a secondary sublayout that is an "itemlayout", which would be typed to itemkey and drops the tempdata check. At least provides compile-time checking as long as developers use the itemlayout for item subscreens. But, call me crazy, that's worse because now all of my derived view's viewmodels have to depend on the type from the itemlayout viewmodel. However, this has the advantage of making the dependency clear: if you're going to use this layout, you must derive from this viewmodel that contains an itemkey property. This seems like the most idiomatic way, but I hate the idea of a typed layout.

4. Move the navbar on to every view page. I will almost certainly not do this, but it should be mentioned that the possibility exists.

So, is there another way I could perform this action idiomatically in MVC, or is one of the options I've listed above the preferred method?

Answer 1

TempData is a bad way to send data around in an ASP.NET MVC application. It's a holdover from the Viewstate days. It's a bad idea.

Instead of TempData, you can make your Navbar a RenderAction, and pass it information from each page it appears on (from the view). You can also use an HtmlHelper (outlined below) to render the links. There's no sense in having all this cooped up in the Layout.cshtml, since it'll have code that doesn't apply to it.

Effectively what you're trying to do is show the active page in a different style.

There are quite a few ways of doing that.

• Highlighting current page ASP.NET MVC
• Highlighting current page in navigation ASP.NET MVC

And K. Scott Allen has a blog post about the various methods he uses.

All of this tricks have one thing in common: They all suggest using an HTMLHelper that simply looks at the current page.

Answer 2

The most natural and canonical way to do this in MVC is by overriding partials. Create a specific controller called SearchController.

Then, create a partial called _Navigation.cshtml in your "Views\Shared" folder, like this:

<nav>
    <div class="container">
        <ul>
            <li>...</li>
            <li>...</li>
            <li>...</li>
        </ul>
    </div>
</nav>

And then, in "Views\Search" create another partial called _Navigation.cshtml like this:

<nav>
    <div class="container">
        <p>Nothing to see here.</p>
    </div>
</nav>

Then, in your layout, when you do this:

@Html.Partial("_Navigation")

The precedence of the view resolver will pick up the latter on the search page and the former everywhere else.

Edit: Based on what I can gather from your comments and updates, you have a controller action that receives some values in the query string and you want to persist those in your action links. The answer is easy.

Assuming the URL /UpdateLog?Upc=xyz&VendorItemCode=abc&Vendor=1 hits your UpdateLog.Index action, then in your view, your links just need to be, e.g.:

@Html.ActionLink("Purchasing", "Index", "InvoiceMovementHistory")

If InvoiceMovementHistory.Index also accepts those parameters, the MVC framework will automatically map the current route parameters to the target route when it is generating the link. No need for you to manage the values at all.

If they're not query string parameters but URL segments, the same applies.

This stateless passing of context from request to request via GET parameters is the ultimate "idiomatic" way of doing this sort of thing in MVC and on the web in general.

Use this in conjunction with the view overriding I described above and you have a very easy way of doing this and switching the nav off for specific pages. That said, given the emerging clarity I would forego the partials and just check a ViewBag.DisableNav property in your layout:

@if (!ViewBag.DisableNav)
{
    <nav>
        <div class="container">
            <ul>
                <li>@Html.ActionLink("Purchasing", "Index",
                                     "InvoiceMovementHistory")</li>
                <li>...</li>
                <li>...</li>
            </ul>
        </div>
    </nav>
}