Tips for Managing ASP.NET MVC Views

After working on an ongoing ASP.NET MVC project for a couple of months I’ve learned a couple of lessons when it comes to dealing with Views.  Keep as much logic out of the views as possible! This can be tricky because it’s so easy to let code sneak into your views. But by following the tips below you’ll be able to keep your logic organized and views clean.

1) Follow the Rails pattern of having a Helper class for each controller.  The helper class deals with html snippets or formatting functions on a per controller level.


Pushing out bits of code like date formatting into helper classes not only cleans up the views, but aids in testability.  Logic is consolidated in one place simplifying maintenance.  Creating Helpers on a per controller level also creates a namespace where functionality can be found intuitively.
2) Don’t overload the Html helper with one-off functions. Organize functions into their respective helper classes.

It’s so easy to want to add extension methods to the HtmlHelper class.  It’s like a siren crying out “do it, do it”.  This is bad!  Extension methods are good for some things, but can easily garble an API.  The HtmlHelper class should be reserved for rendering core html elements.  As an alternative, leverage helper classes you create on a per-controller basis.

3) Leverage partial views for iterative content, even if it’s not reused elsewhere (hint: it probably will be eventually).

So instead of:


This will greatly minimize the amount of markup scattered throughout a view, keeping view files focused on a specific task (just like good class design).  It’ll also make version control easier because changes will be isolated to their respective file, allowing someone to better see what changes happened where.  It also eliminates excessive merging.

4) Organize partial views within their respective controller, not a shared folder- even if it’s a global skin.

Dumping partials within a shared folder can cause overcrowding and jumbling in the long term.  Prefer organization and grouping of related content (again, just like good class design).
5) Prefer a strongly typed view and leverage specialized ViewData types for aggregating random models under one root.

It can be easy to dump stuff into the ViewData hash.  However, prefer using a custom ViewData class instead.  It’s easier to know what data is available for the view.  This is a lot more intuitive than rummaging through a controller, which happens when teams share code.  Also leverage the null object pattern for properties to avoid having to do null reference checks in the views.

Instead of:


6) Minimize code snippets in views.

Code snippets occur in many ways.  They can be as simple as formatting a date, to string concatenation, to even doing a grouping/projection to get data correct.  Doing this in a view easily leads to bugs and isn’t testable.  Any data processing specifically for views should occur in the controller action, custom ViewData object itself, or in a helper class.  Code in views should be simplified to looping, calling a property, or calling a single method.  Anything more than that will get you into trouble!
Leverage RenderAction or MvcContrib’s SubController for dealing with shared isolated functionality not relevant to a view.

Unfortunately, as of RC1 there still isn’t a great way to deal with aggregating disparate content in an action.  You’ll need to resort to the RenderAction in the Future’s dll or use MvcContrib’s SubController.  The point is the same- keep actions specific to what you’re doing.  If you need to aggregate disparate content in a view (like a menu in the header, or a shopping cart) offload functionality into an action and call RenderAction.  Having actions do multiple, random things leads to messy code.  Prefer a single point of entry into supporting view content.

Good luck and share your tips!

kick it on

  • Pingback: DotNetShoutout()

  • Garry

    Great tips, thanks. I am currently working on an MVC project and I will certainly look into the ViewData class objects instead of using a hash. Also partials isn’t something I have considered much as yet, but I will have to do some research on that as your argument for reuse is a very valid one.

  • Christian Weiss

    Nice, thanks! I’m working on a MVC project for a longer time too and agree with your points!

  • Mike Stokes

    Great summary of tips Michael. I’m sure a lot of people new to MVC from WebForms are struggling and this gives them a quick and easy set of tips to follow.

  • Pingback: ASP.NET MVC Archived Blog Posts, Page 1()

  • Billy McCafferty

    Good tips…here’s one more for ya: use areas organized under the views folder to split large applications into appropriately sized modules (

  • mycall

    Have you considered calling them Extension Classes instead of helper Classes? explains the Helper Pattern better than I could.

  • trendbender

    good article, thx

  • Pingback: ASP.NET MVC Archived Buzz, Page 1()

  • Pingback: Feb Link Round Up ::

  • Pingback: Joan()

  • Andy

    Please check your site in Chrome. Right column overlaps main body text and can’t be read.

  • Andy

    In Firefox too

  • Andy

    And it’s really screwed in IE

  • Michael