12 ASP.NET MVC Best Practices
You will never use it and it’s a super-bad practice to keep demo code in your applications. 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. 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. 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. 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. 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. 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 useAutoMapper. For a nice overview of the various options I recommend you read: ASP.NET MVC View Model Patterns. 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. NEVER 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 (likeHtml.Submit or Html.Button). Again, this is something that might become a future post. 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. The default view engine is the WebFormViewEngine, but IMHO it’s NOT the best one. I prefer to use theSpark 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”. Both the slides and the demo code are available for download.1 – Delete the AccountController
2 – Isolate Controllers from the outside World
3 – Use an IoC Container
4 – Say NO to “magic strings”
5 – Build your own “personal conventions”
6 – Pay attention to the Verbs
Model’s Best Practices
7 – DomainModel != ViewModel
8 – Use ActionFilters for “shared” data
View’s Best Practices
9 – Do NEVER user code-behind
10 – Write HTML each time you can
11 - If there is an if, write an HtmlHelper
12 – Choose your view engine carefully
Download the slides and demo
Source: CodeClimbber
Excelente producto! Para la gente que anda continuamente con su laptop.
