Asp. NET routing system: separation of URLs from physical files

The URL routing system, which behaves as a dynamic mapping of the request address and the target Controller and action, is not exclusive to ASP.net MVC, but is built directly in asp.net. Asp. NET realizes the separation of the request address and the physical file through the URL routing system.

The separation of the URL and the physical file

For a asp.net Web form application, any request corresponds to a specific physical file. Physical files that are deployed on a Web server can be static (such as pictures and static HTML files, etc.) or dynamic (such as. asxp files). For static file requests, ASP. NET directly returns the entire contents of the file, while requests for dynamic files trigger the execution of the relevant code and eventually return the execution result. But the way in which URLs are tightly bound to physical files is not a good solution, and its limitations are mainly embodied in the following areas:

Flexibility: because a URL is a reflection of the physical file path, it means that if the path to the physical file changes (such as changing the file's directory structure or file name), the original link to the file will become invalid.

readability: In many cases, URLs need not only access to the right network resources, but also good readability, and the best URLs should give us a glimpse of what the target resource is for it to access. The close binding of the request address to the physical file has completely deprived us of the opportunity to define a highly readable URL.

SEO optimization: for Web development, in order to meet the search engine retrieval rules, we need to effectively design the URL to make it easy to be the mainstream engine retrieval. If the URL is completely associated with the physical address, this is tantamount to the loss of SEO optimization capabilities.

For the above limitations of URL and physical file binding mechanism, we need a more flexible mechanism to separate the request address of the physical file from the path of the file itself, and to implement the link between the URL and the physical file through a dynamic mapping mechanism.

When it comes to this, many people may think of URL rewriting. To allow Web applications to independently involve URLs for accessing application resources, Microsoft has written a URL rewrite module for IIS 7. This is a rule-based URL rewrite engine that changes the URL of the request before the URL is processed by the Web server. For dynamic Web applications, it can provide users and search engines with friendly Url,url overrides and redirects based on HTTP headers and server variables, and can access control of site content.

URL rewriting resolves the separation of URLs from physical addresses at the IIS level, which is registered with a local (Native) code-based module on a pipeline for HTTP request processing by IIS, so it can be applied to Web applications that are hosted in IIS. The URL routing system is part of the ASP.net and is implemented through managed code. To give the reader a sense of the asp.net URL route, let's demonstrate a simple example.

Second, example demo: Through the URL route implementation of the request address and the. aspx page mapping

Next we will create a simple asp.net Web Forms application and use a URL that is separate from the. aspx file path to access the corresponding Web page, and the mappings between the two are implemented through URL routing. We are an employee management scenario where we will create a page that displays a list of employees and details of an employee, and the page renders the effect as shown below.

We will focus on the URLs of the two pages shown above. The page address used to display the list of employees is http://localhost:2738/employees. When a user clicks on a connection displayed as a name, the page that displays the details of the selected employee is rendered, and the URL mode of the page address is http://localhost:2738/employees/{name}/{id}. For the latter, one glance at the end user can see from the URL which employee's information was obtained through the address. One might ask, why should we include both the employee's name and ID in the URL? This is because the ID (in this case, the GUID) is less readable than the employee name, but the employee name is not unique, and the ID we use here is a unique identification provided for the logical processing needs, and the name is for readability.

We define all information (ID, name, gender, date of birth, and department) of the employee in the employee type as shown below. As usual, we define a employeerepository type that represents a domain model for maintaining a list of employees. The list of maintained employees is represented by a static field employees. The Employeerepository GetEmployees method returns a list of the corresponding employees according to the specified ID, and returns a list of all employees if the specified ID is "*"

1:public class Employee
2: {
3:public string Id {get; private set;}
4:public string Name {get; private set;}
5:public string Gender {get; private set;}
6:public DateTime birthdate {get; private set;}
7:public string Department {get; private set;}
8:
9:public Employee (string ID, string name, string gender, DateTime birthdate, string Department)
10: {
11:this. id = ID;
12:this. name = name;
13:this. Gender = Gender;
14:this. Birthdate = birthdate;
15:this. Department = Department;
16:}
17:}
18:public class Employeerepository
19: {
20:private Static ilist<employee> employees;
21:static Employeerepository ()
22: {
23:employees = new list<employee> ();
24:employees. ADD (New Employee (GUID.NEWGUID). ToString (), "John", "Male", New DateTime (1981, 8, 24), "Sales Department");
25:employees. ADD (New Employee (GUID.NEWGUID). ToString (), "Dick", "female", New DateTime (1982, 7, 10), "Ministry of Personnel");
26:employees. ADD (New Employee (GUID.NEWGUID). ToString (), "Harry", "Male", New DateTime (1981, 9, 21), "Ministry of Personnel");
27:}
28:public ienumerable<employee> getemployees (String id = "")
29: {
30:return employees. Where (e => e.id = = Id | | string. IsNullOrEmpty (ID) | | id== "*");
31:}
32:}