12 ASP.NET MVC Best Practices

Last week I held two presentations about ASP.NET MVC for the new-born DotNetRomaCeStà user group in Rome. And one of them was about what I consider to be ASP.NET MVC Best Practices. The presentation was in Italian so I decided to translate my slide in English so that everybody can read them.

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

Dependencies on the HttpContext, on data access classes, configuration, logging, clock, etc… make the application difficult (if not impossible) to test, to evolve 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. I use Ninject v2, but 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 then 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. For a nice overview of the various options I recommend you read: ASP.NET MVC View Model Patterns.

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”.

Download the slides and demo

Both the slides and the demo code are available for download. Or watch it here: ASP.NET MVC Best Practices