ASP.NET MVC – 12 Best Practices

As a web developer you might still not sure that should you or should not upgrade your ASP.NET to ASP.NET MVC.  Here are 12 Best Practices of ASP.NET MVC for you to considerate.

Controller’s best practices

1. Delete the AccountController

You will never use it and it’s a super-bad practice to keep demo code in your applications.

2. Isolate Controllers from the outside world

Reliances on the HttpContext, on data access classes, configuration, logging, clock, etc… make the application hard (if not impossible) to test, to develop and modify.

3.Use an IoC Container

To make it easy to adhere to Best Practice #2, use an IoC Container to manage all that external dependencies. There are many around, and it’s easy to build your own if needed.

4. Say NO to “magic strings”

Never use ViewData[“key”] but always create a ViewModel per each View, and use strongly-typed views ViewPage<ViewModel>.

Magic strings are evil because they will never tell you whether your view is failing due to a misspelling error, while using a strongly-typed model you will get a compile-time error when there is a problem. And as bonus you get Intellisense.

5. Build your own “personal conventions”

Use ASP.NET MVC as a base for your (or your company’s) reference architecture. Enforce your own conventions having controllers and maybe views inherit from your own base classes rather than the default ones.

6. Pay attention to the Verbs

Even without going REST (just RESTful) use the best Http Verb for each action. Adopt the PRG Pattern (Post-Redirect-Get): show data with GET, modify data with POST.

Model’s Best Practices

7. DomainModel != ViewModel

The DomainModel represents the domain, while the ViewModel is designed around the needs of the View, and these two worlds might be (and usually are) different. Furthermore the DomainModel is data plus behaviours, is hierarchical and is made of complex types, while the ViewModel is just a DTO, flat, and made of strings. To remove the tedious and error-prone object-mapping code, you can use AutoMapper.

8. Use ActionFilters for “shared” data

This is my solution for the componentization story of ASP.NET MVC, and might need a future post of its own. You don’t want your controllers to retrieve data that is shared among different views. My approach is to use the Action Filters to retrieve the data that needs to be shared across many views, and use partial view to display them.

View’s Best Practices

9. Do NEVER user code-behind

NEVER

10. Write HTML each time you can

I have the option that web developers have to be comfortable writing HTML (and CSS and JavaScript). So they should never use the HtmlHelpers whose only reason of living is hiding the HTML away (like Html.Submit or Html.Button). Again, this is something that might become a future post.

11. If there is an ‘if’, write an HtmlHelper

Views must be dumb (and Controllers skinny and Models fat). If you find yourself writing an “if”, then consider writing an HtmlHelper to hide the conditional statement.

12. Choose your view engine carefully

The default view engine is the WebFormViewEngine, but IMHO it’s NOT the best one. I prefer to use the Spark ViewEngine, since it seems to me like it’s more suited for an MVC view. What I like about it is that the HTML “dominates the flow and that code should fit seamlessly” and the foreach loops and if statements are defined with “HTML attributes”.

Which other Best Practices would you suggest?

The 12 above are what I consider basic practices that everyone building ASP.NET MVC applications should adopt. Do you think there are other must-have practices for developers building ASP.NET MVC applications?

Existing clients can build and deploy ASP.NET MVC projects into web server immediately. SeekDotNet.com welcomes more new clients to sign up for ASP.NET MVC supported web hosting plans. For information on ASP.NET MVC hosting, please visit http://www.seekdotnet.com/aspnetmvchosting.aspx