July 20, 2010 at 15:03ASP.NET MVC: My Rules for Views
- Transfer
I have been working with the team on several ASP.NET MVC projects since October 2009. Although not much time has passed and I am not an expert yet, I want to describe a number of rules that we have developed in order to make the code a little better. ASP.NET MVC, like any new technology, may not be used successfully, but having unsuccessful examples, we always try to make the code better by choosing the best options for implementing tasks.
First, let's think about the tasks of the View, its main function is to insert data into HTML. This rule excludes discrepancies - do not receive data, do not transmit data, but simply embed data in HTML. And frankly, this is quite complicated. The approach that I always try to adhere to is to create page markup (aspx) as close as possible to the resulting HTML. The main reason for this approach is to bring the original markup closer to the resulting one, thus eliminating double work. I want to see the “div” in the original markup, and be sure that the “div” will also be in the resulting HTML.
Do not take this rule literally, the code should still be in the View. For example, a simple “for” loop to create a table, or an “if” to display the administrator’s functionality, but you don’t have to determine the date format time or parsing strings - this is what the Model should do for the View. Make an approximate calculation - if you see more C # code than HTML, then you did something wrong.
I also apply this rule for Javascript. I used to say why Javascript should not be in the view, therefore, this should not be a shock to you. Store JavaScipt in separate files.
This is true for all views where you must pass data from the Controller to the View. Make a View Model for the View, and transfer the data through the Model. This opens up a number of possibilities for you, such as typed HtmlHelper s. As a result, it very rarely happens when I use the View Model between Views or even Controller Actions. I make separate models for GET, POST and DELETE. The more the merrier.
Yes, this is not the best way to implement Views, at first glance. If you make the View Model too general, in the end, you will have to implement a lot of logic in the View to transfer data. The key point is that the data in the model serves to represent, so all the work of getting the data in the correct format should be done when transferring data to the model. I always keep this in arms, especially when the Model needs to define classes for html CSS elements. How, in Views, I have much more than data from the database.
Note: when the use of the View Model becomes popular, with the data sharpened for the View, AutoMapper will become very popular.
Creating your own Html Helper is very simple, and as soon as you learn how to do it, you will understand that they are beautiful. This is an easy way to encapsulate some logic and remove it from the View. Use them to encapsulate the code that you use in different parts of the project.
Another little trick I sometimes use is creating Models specifically for Html Helper s. I have several places in the project where I have to change the layout depending on the browser used, for this I create an Html Helper that defines the browser.
The meaning of this rule is to understand what markup standard HTML Helpers produce. Despite the usefulness of HTML Helper, they have some disadvantages (any modifications to the attributes “name” or “value” are very unpleasant). Sometimes it’s much easier to replace them with standard HTML (especially input) to get a more predictable result. As a bonus, this will make it easier for a new employee to understand your code. At the moment, I use 50/50 HTML Helper and HTML.
Using standard HTML or HTML Helper elements is pretty tedious. You are forced to enter the same code over and over again. I recommend paying attention to Zen-Coding. You can do the same with ReSharper Templates or Visual Studio Snippets by installing the appropriate plugins. In addition, the art of customizing Visual Studio is what you need to learn.
You have a web application in which you navigate through pages, call web services, links to javascript and CSS. Typical project. All of these links should be wrapped in Url.Content or Url.Action helper s. This solves a number of common problems when testing or deploying an application. For example, you are testing an application on localhost: 898989 /, and you need to deploy it to myserver / myapp /, while a significant part of the links will stop functioning. Using Url.Content and Url.Action solve this problem, so I always use them.
Partial Views are Views that do not have a master page and html and body tags. They can be used both in other representations on the server, and in Javascript on the client. JQuery has a great $ .load method that executes a request to the specified url and then inserts the resulting html markup into the page. This proves to be very useful in a number of cases.
Sometimes I use a little trick - I wrap markup fragments that are loaded into Partial Views for a long time. Then, after the page loads, I get the data from the Partial View (using the Javascript setTimeout function to call $ .load). Thus, I get a page that loads quickly, while it has all the necessary data.
This does not mean that initially there is something wrong with the Master page, which is provided to you when creating the Asp.net MVC project. On the contrary, in 80% of cases, this is exactly what you need. But as soon as I find out what my main page should do, I remove everything superfluous from the Master page. Also, do not forget about the inheritance of the Master page.
Even if he is not. This is the main pattern that I adhere to. I imagine a designer who taking pure html and css can make my site much more attractive. This means that I use pure html wherever possible, I write Javascript button click handlers in such a way that they work with buttons and links as well (recommendation: always return false, and as I haven't written a jQuery plugin for this yet) .
This is actually the topic of my next post, but nevertheless, we will briefly touch on the topic of css and Javascript versioning. In fact, this is not specificity of MVC, it is worth using in all web projects. The goal is to solve problems with the browser cache. You know that the first thing you ask of someone who asks for your help is whether he cleared the browser cache. In my opinion, it is worthwhile to install an automatic update of the assembly version, then attach the version number to the end of each Javascript file. It should look like this: "myapp / ... / file.css? Version = 1.0.0.256." Also, I use adding timestamp in a similar way.
Be published at the request of a friend. Unfortunately, I can’t throw the invite myself, so anyone who wants it can invite him to the mail dimaumen [at] ukr [dot] net.
First, let's think about the tasks of the View, its main function is to insert data into HTML. This rule excludes discrepancies - do not receive data, do not transmit data, but simply embed data in HTML. And frankly, this is quite complicated. The approach that I always try to adhere to is to create page markup (aspx) as close as possible to the resulting HTML. The main reason for this approach is to bring the original markup closer to the resulting one, thus eliminating double work. I want to see the “div” in the original markup, and be sure that the “div” will also be in the resulting HTML.
1. Use as little code as possible in views
Do not take this rule literally, the code should still be in the View. For example, a simple “for” loop to create a table, or an “if” to display the administrator’s functionality, but you don’t have to determine the date format time or parsing strings - this is what the Model should do for the View. Make an approximate calculation - if you see more C # code than HTML, then you did something wrong.
I also apply this rule for Javascript. I used to say why Javascript should not be in the view, therefore, this should not be a shock to you. Store JavaScipt in separate files.
2. Use Typed Views
This is true for all views where you must pass data from the Controller to the View. Make a View Model for the View, and transfer the data through the Model. This opens up a number of possibilities for you, such as typed HtmlHelper s. As a result, it very rarely happens when I use the View Model between Views or even Controller Actions. I make separate models for GET, POST and DELETE. The more the merrier.
3. Create View Models for specific View tasks
Yes, this is not the best way to implement Views, at first glance. If you make the View Model too general, in the end, you will have to implement a lot of logic in the View to transfer data. The key point is that the data in the model serves to represent, so all the work of getting the data in the correct format should be done when transferring data to the model. I always keep this in arms, especially when the Model needs to define classes for html CSS elements. How, in Views, I have much more than data from the database.
Note: when the use of the View Model becomes popular, with the data sharpened for the View, AutoMapper will become very popular.
4. Own Html Helpers are a great thing
Creating your own Html Helper is very simple, and as soon as you learn how to do it, you will understand that they are beautiful. This is an easy way to encapsulate some logic and remove it from the View. Use them to encapsulate the code that you use in different parts of the project.
Another little trick I sometimes use is creating Models specifically for Html Helper s. I have several places in the project where I have to change the layout depending on the browser used, for this I create an Html Helper that defines the browser.
5. Standard HTML Helper - it's great, but do not forget about HTML
The meaning of this rule is to understand what markup standard HTML Helpers produce. Despite the usefulness of HTML Helper, they have some disadvantages (any modifications to the attributes “name” or “value” are very unpleasant). Sometimes it’s much easier to replace them with standard HTML (especially input) to get a more predictable result. As a bonus, this will make it easier for a new employee to understand your code. At the moment, I use 50/50 HTML Helper and HTML.
Using standard HTML or HTML Helper elements is pretty tedious. You are forced to enter the same code over and over again. I recommend paying attention to Zen-Coding. You can do the same with ReSharper Templates or Visual Studio Snippets by installing the appropriate plugins. In addition, the art of customizing Visual Studio is what you need to learn.
6. Wrap all links in Url.Content or Url.Action
You have a web application in which you navigate through pages, call web services, links to javascript and CSS. Typical project. All of these links should be wrapped in Url.Content or Url.Action helper s. This solves a number of common problems when testing or deploying an application. For example, you are testing an application on localhost: 898989 /, and you need to deploy it to myserver / myapp /, while a significant part of the links will stop functioning. Using Url.Content and Url.Action solve this problem, so I always use them.
7. Adopt Partial Views in conjunction with Ajax requests
Partial Views are Views that do not have a master page and html and body tags. They can be used both in other representations on the server, and in Javascript on the client. JQuery has a great $ .load method that executes a request to the specified url and then inserts the resulting html markup into the page. This proves to be very useful in a number of cases.
Sometimes I use a little trick - I wrap markup fragments that are loaded into Partial Views for a long time. Then, after the page loads, I get the data from the Partial View (using the Javascript setTimeout function to call $ .load). Thus, I get a page that loads quickly, while it has all the necessary data.
8. Make the master page work for you
This does not mean that initially there is something wrong with the Master page, which is provided to you when creating the Asp.net MVC project. On the contrary, in 80% of cases, this is exactly what you need. But as soon as I find out what my main page should do, I remove everything superfluous from the Master page. Also, do not forget about the inheritance of the Master page.
9. Think about what the designer needs.
Even if he is not. This is the main pattern that I adhere to. I imagine a designer who taking pure html and css can make my site much more attractive. This means that I use pure html wherever possible, I write Javascript button click handlers in such a way that they work with buttons and links as well (recommendation: always return false, and as I haven't written a jQuery plugin for this yet) .
10. Css and Javascript Versioning
This is actually the topic of my next post, but nevertheless, we will briefly touch on the topic of css and Javascript versioning. In fact, this is not specificity of MVC, it is worth using in all web projects. The goal is to solve problems with the browser cache. You know that the first thing you ask of someone who asks for your help is whether he cleared the browser cache. In my opinion, it is worthwhile to install an automatic update of the assembly version, then attach the version number to the end of each Javascript file. It should look like this: "myapp / ... / file.css? Version = 1.0.0.256." Also, I use adding timestamp in a similar way.
Be published at the request of a friend. Unfortunately, I can’t throw the invite myself, so anyone who wants it can invite him to the mail dimaumen [at] ukr [dot] net.