Is menu link suppression a responsibility of the view or the controller?

Question

In ASP.NET MVC, I am building a site with the requirement that the main menu (appearing on every page) should remove the hyperlink for an entry (leaving just the text) if the current page is the one linked to.

The menu html is defined in the master page for the site, but is currently populated from the ViewData passed by the controller. This is set up so that the base controller defines a dictionary of link objects, then the actions on the controllers grab the relevant entry out of the dictionary, set the address to empty. The base controller then passes it to the view as an IEnumerable<>.

However, looking at it with a critical eye, it feels more like something the view should have sole responsibility for: the menu doesn't change, so the controller feels like it's butting in where it shouldn't. My only slight reservation is that the View would be knowledgable about what the current page is, which feels like more of a controller concern.

I've been arguing around in circles in my head for a while now, so I'd like some other opinions on this. I would have thought this would be a fairly common scenario?

(One final clarification to my problem: the main menu links are to "landing pages" of the various areas of the site (basically the Index action of all the controllers), and once you've navigated into the area and are off the landing page, all entries in the menu will be linked)

Answer 1

We might like to think of views as being very dumb in that their only task is to turn the data provided by the controller into something that the client can parse and display.

However in fact most views (certainly all the examples of ASP.NET-MVC I've seen) considerable application logic is embodied in the views in that its the view which dictates how the user can navigate around the application. If it were not for the view including code to create clickable links, images and buttons we wouldn't have much of an application.

Hence a view having a menu which it controls the content of is not contrary to the spirit of the separation of concerns. OTH, a controller providing some from of list to be turned into a menu is also acceptable. In that case you would expect the controller to dictate which members of the menu should be available to click, the views role in this scenario would be to carry out the wishes of the controller.

Answer 2

I'd go for creating a controller for menu display. Putting too much logic into the view makes it harder to maintain, I think.

Not showing the user manu entries that he can't use, for some reasons, is a part of your application logic rather then the view itself. I always try to treat view as a dumb part of code that just does what's needed - loops, basic display-related ifs, such things.

Also passing just enough important data to the view might make the application easier to test.

Answer 3

I agree with AWJones that it's a bit grey area, but imho if the view should be responsible for how something is presented and the controller for what that something is, then the contents of the menu are in the domain of the controller.

I kind of feel the "suppression" of parts of the menu should be hidden from the view (and the end user) entirely - the view should get what it needs and no more.