Click here to Skip to main content
Click here to Skip to main content
Go to top

ASP.NET MVC Best Practices

, 11 Oct 2013
Rate this:
Please Sign up or sign in to vote.
The ASP.NET MVC is becoming more and more popular each day.  As the application grows in size so does the maintenance nightmare.  Following are some

Editorial Note

This articles was originally at wiki.asp.net but has now been given a new home on CodeProject. Editing rights for this article has been set at Bronze or above, so please go in and edit and update this article to keep it fresh and relevant.

The ASP.NET MVC is becoming more and more popular each day.  As the application grows in size so does the maintenance nightmare.  Following are some of the better practices, that if followed, may help maintain our application and also provides a means of scalability as the demand increases.  Feel free to add/update practices/tips as required.

 Do note that this checklist are just for quick reference and are not detailed materials and can be used as a quick reference.  

  1. Isolate Controllers
    Isolate the controllers from dependencies on HttpContext, data access classes, configuration, logging etc.  Isolation could be achieved by creating wrapper classes and using an IOC container for passing in these dependencies

  2. IoC Container
    Use an IoC container to manage all external dependencies  The following are some of the wellknown containers/framework.
    1. Ninject
    2. Autofac
    3. StructureMap
    4. Unity Block
    5. Castle Windsor

  3. No "magic strings"
    Never use magic strings in your code. This means hard-coding view names, link text etc. into your views. Frameworks such as T4MVC can help with this.  More to come on this.

  4. Create a ViewModel for each view
    Create a specialized ViewModel for each view.  The role of ViewModel should only be databinding.  It should not contain any presentation logic.

  5. HtmlHelper
    For generating view html use HtmlHelper.  If  the current HtmlHelper is not sufficient extend it using extension methods.  This will keep the design in check.

  6. Action Methods
    Decorate your action methods with appropriate verbs like Get or Post as applicable.

  7. Caching
    Decorate your most used action methods with OutputCache attribute.

  8. Controller and Domain logic
    Try to keep away domain logic from controller.  Controller should only be responsible for
    1. Input validation and sanitization.
    2. Get view related data from the model.
    3. Return the appropriate view or redirect to another appropriate action method.

  9. Use PRG pattern for data modification
    PRG stands for Post-Redirect-Get to avoid the classic browser warning when refreshing a page after post.  Whenever you make a POST request, once the request complets do a redirect so that a GET request is fired.  In this way when the user refresh the page, the last GET request will be executed rather than the POST thereby avoiding unnecessary usability issue. It can also prevent the initial request being executed twice, thus avoiding possible duplication issues.

  10. Routing
    Design your routes carefully.  The classic route debugger comes to rescue http://haacked.com/archive/2008/03/13/url-routing-debugger.aspx

  11. There should be no domain logic in the views. Views must be, only, responsible for showing the data.

  12. Views should not contain presentation logic
    Views should not contain any presentation logic.  For e.g. If a "Delete" button is to be displayed only for "Admin" role this should be abstracted away in an Html Helper.  This is just an example and there will be many scenarios which will require this abstraction for easy maintenance of views. 

  13. Use POST for "Delete" links instead of GET
    Using Delete links (GET) is more vulnerable than using POST.  Here is a detailed post on this along with a couple of alternatives.
    http://stephenwalther.com/blog/archive/2009/01/21/asp.net-mvc-tip-46-ndash-donrsquot-use-delete-links-because.aspx

   

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

ASP.NET Community

United States United States
The ASP.NET Wiki was started by Scott Hanselman in February of 2008. The idea is that folks spend a lot of time trolling the blogs, googlinglive-searching for answers to common "How To" questions. There's piles of fantastic community-created and MSFT-created content out there, but if it's not found by a search engine and the right combination of keywords, it's often lost.
 
The ASP.NET Wiki articles moved to CodeProject in October 2013 and will live on, loved, protected and updated by the community.
Group type: Collaborative Group

247 members


Comments and Discussions

 
Suggestion5 Stars PinmemberWillian Arsenio10-Feb-14 5:29 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.140926.1 | Last Updated 11 Oct 2013
Article Copyright 2013 by ASP.NET Community
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid