ASP.NET MVC Best Practices

The marvelous technology inception from Microsoft, ASP.NET has for the past few years conquered the favoritism of a large section of the web application development community owing to its maturity and stability. The passage of time has rendered the ASP.Net not obsolete but a little behind times maybe. The subsequent updates have surfaced and the Model View Controller (MVC) is the apt alternative available today.

The server controls necessary in earlier versions are rendered redundant for producing HTML pages. The most prime feature which concerns offshore web development in the IT services field is that ASP.NET MVC is based on the handling of HTTP requests. The only exceptions exist in the form of URL strings which are treated in a different manner. The URL constructed in case of ASP.NET MVC point out to actions to occur and not generally to files that need processing. ASP.NET MVC mostly is not bound to server controls or other similar technologies.

Controller’s best practices

1. Delete the account controller

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

2. Isolate controller 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.

4. Say NO to “magic strings”

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

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.

Model’s best practices

7. DomainModel ! = View Model

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.

8. Use ActionFilters for “shared” data

This is our 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

10. Write HTML each time you can

We 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. We prefer to use the Spark ViewEngine, since it seems to me like it’s more suited for an MVC view. What we 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”.