12 Best ASP.NET MVC Practices
- Transfer
From the translator: here are 12 good practices that the author recommends to use when developing ASP.NET MVC applications. I decided to translate this short list for those who are just looking at ASP.NET MVC and taking the first steps in this framework. I hope these tips will help you better understand the architecture of ASP.NET MVC and make the right decisions when developing projects. Some tips are controversial, but do not forget that the author expresses his opinion, which may not coincide with yours.
1. Delete AccountController
You will never use it and it is a super bad practice to leave demo code in your applications.
2. Hide controllers from the outside World
Depending on the HttpContext, data access classes, configuration, logging, clocks, etc., create difficulties for your application in testing (or not testing at all), in further development and modification.
3. Use an IoC container
In order to adhere to rule # 2, use an IoC container to manage all external dependencies. I use Ninject v2 , but there are many containers and, in addition, you can easily build your own container.
4. Say NO to magic lines
Never use ViewData [“key”], but always create a ViewModel for each View and use strongly typed ViewPage views.
Magic strings are evil because they will not tell you about a grammatical error if you allow it, because of which your presentation does not work, instead, using strictly typed models, you can determine the source of the problem even at the compilation stage. And, as a bonus, you get IntelliSense.
5. Build your own conventions
Use ASP.NET MVC as the basis for your (or your company) architecture. Create your own conventions with basic controllers or even views from which your classes will be inherited, instead of using the default classes.
6. Pay attention to request types (Verbs)
Even if you are not using the REST model (just RESTfull), use a specific Http request type for each action. Accept the PRG (Post-Redirect-Get) pattern : show data with a GET request, modify data with POST requests.
7. Domain
model ! = ViewModel The domain model represents the domain, while ViewModel implies the satisfaction of the needs of your presentation, and these two worlds are (and usually are) different. In addition, the domain model is data plus behavior, it is a hierarchy and is built on the basis of complex types, while ViewModel is just DTO (Data Transfer Objects), a flat model based on strings. You can use AutoMapper to avoid tedious and error-prone object mapping code . Also, I recommend reading a good review: ASP.NET MVC View Model Patterns .
8. Use ActionFilters for shared data.
This is my solution for the best component model of ASP.NET MVC and in the future I should be writing a few more articles on this topic. You do not need controllers to receive data that is shared between different views. My solution is to use the Action Filter to get the data you need and share it between the views. And use partial views to display.
9. NEVER use code-behind
NEVER.
10. Write HTML every time there is such an opportunity.
I believe that it is convenient for web developers to write HTML (both CSS and JavaScript). Therefore, they should not use HtmlHelpers just to hide the HTML (for example, in the form of Html.Submit or Html.Button). And again, this topic is for future articles.
11. If there is if, write HtmlHelper.
Views should be dumb (and controllers should be skinny and models should be thick). If you suddenly find yourself writing “if” in a view, then consider creating an HtmlHelper to hide the conditional expression.
12. Pay attention to the choice of your view engine
By default, ASP.NET MVC uses WebFormViewEngine, but in my opinion, this is not the best choice. I prefer to use the Spark View Engine , since this tool seems to me more suitable for MVC. What I like about it is that the stream is built on HTML and the “foreach” loops and the “if” expressions are defined via the “HTML attributes”.
Both slides and demo code are available for download. Or you can watch slides online .
Controller best practices
1. Delete AccountController
You will never use it and it is a super bad practice to leave demo code in your applications.
2. Hide controllers from the outside World
Depending on the HttpContext, data access classes, configuration, logging, clocks, etc., create difficulties for your application in testing (or not testing at all), in further development and modification.
3. Use an IoC container
In order to adhere to rule # 2, use an IoC container to manage all external dependencies. I use Ninject v2 , but there are many containers and, in addition, you can easily build your own container.
4. Say NO to magic lines
Never use ViewData [“key”], but always create a ViewModel for each View and use strongly typed ViewPage views.
Magic strings are evil because they will not tell you about a grammatical error if you allow it, because of which your presentation does not work, instead, using strictly typed models, you can determine the source of the problem even at the compilation stage. And, as a bonus, you get IntelliSense.
5. Build your own conventions
Use ASP.NET MVC as the basis for your (or your company) architecture. Create your own conventions with basic controllers or even views from which your classes will be inherited, instead of using the default classes.
6. Pay attention to request types (Verbs)
Even if you are not using the REST model (just RESTfull), use a specific Http request type for each action. Accept the PRG (Post-Redirect-Get) pattern : show data with a GET request, modify data with POST requests.
Best practice models
7. Domain
model ! = ViewModel The domain model represents the domain, while ViewModel implies the satisfaction of the needs of your presentation, and these two worlds are (and usually are) different. In addition, the domain model is data plus behavior, it is a hierarchy and is built on the basis of complex types, while ViewModel is just DTO (Data Transfer Objects), a flat model based on strings. You can use AutoMapper to avoid tedious and error-prone object mapping code . Also, I recommend reading a good review: ASP.NET MVC View Model Patterns .
8. Use ActionFilters for shared data.
This is my solution for the best component model of ASP.NET MVC and in the future I should be writing a few more articles on this topic. You do not need controllers to receive data that is shared between different views. My solution is to use the Action Filter to get the data you need and share it between the views. And use partial views to display.
Best Practices for Performances
9. NEVER use code-behind
NEVER.
10. Write HTML every time there is such an opportunity.
I believe that it is convenient for web developers to write HTML (both CSS and JavaScript). Therefore, they should not use HtmlHelpers just to hide the HTML (for example, in the form of Html.Submit or Html.Button). And again, this topic is for future articles.
11. If there is if, write HtmlHelper.
Views should be dumb (and controllers should be skinny and models should be thick). If you suddenly find yourself writing “if” in a view, then consider creating an HtmlHelper to hide the conditional expression.
12. Pay attention to the choice of your view engine
By default, ASP.NET MVC uses WebFormViewEngine, but in my opinion, this is not the best choice. I prefer to use the Spark View Engine , since this tool seems to me more suitable for MVC. What I like about it is that the stream is built on HTML and the “foreach” loops and the “if” expressions are defined via the “HTML attributes”.
Downloads
Both slides and demo code are available for download. Or you can watch slides online .