Support for Url Routing in ASP. NET 4

Dong David

Among the Web Forms of ASP. NET 4, the most amazing is the full support of the URL Routing mechanism. In the past, in ASP. NET 3.5 SP1, Web Forms began to support URL Routing more or less, which made our website presentation and usage more flexible.

 

In the past, in ASP. NET, we were used to the following URL rendering methods:

Http: // myWebSite/EditProduct. aspx? Id = 1

 

However, in recent years, with the rise of REST-style websites (or REST Web Services), you often see that the website is presented as follows:

Http: // myWebSite/Product/Edit/XBOX

 

The above websites have some advantages. First, the websites can clearly express the functions to be presented or the behaviors to be performed by backend applications. Second, the above URL does not correspond to a certain object file at the backend (. aspx. cs), but through the Routing mechanism to transfer, so compared with the previous web site has a higher security.

That is to say, in this architecture, the URL of an ASP. NET application is no longer only mapped to the path of the object file, but can be used to express the function to be executed. The program code to be processed during actual execution or the webpage that shows the result is not necessarily the entity page pointed to by the website. This also gives us greater flexibility when developing applications. For example, the general blog website url may be "http: // blog/studyhost 』, because most blog websites can be opened to multiple users, every user of course has a website similar to "http: // blog/applicant ID. Of course, it corresponds to ASP. NET backend should be processed by the same set of programs, in the past ASP. NET applications, we have to spend some time to make the website accept such a URL design (converting the parameter from QueryString to the rest style), but now, the URL Routing mechanism can be used quickly and easily.

 

In addition, there is another obvious benefit of using REST-style urls:

Http: // myWebSite/Product/Edit/XBOX

Vs.

Http: // myWebSite/EditProduct. aspx? Id = 1

Compared with traditional websites, it is easier to search and search by Google and other search engines. After all, the XBOX in the website is much easier to understand than the product Id = 1.

 

So how can we use this mechanism in ASP. NET 4? You just need to use the MapPageRoute method through the newly added Routes category to easily specify the URL routing. For example:

View plaincopy to clipboardprint?
Protected void Application_Start (object sender, EventArgs e ){
RouteTable. Routes. MapPageRoute (
"TestRoute", "Search/{ProductName }","~ /WebForm1.aspx ");
}
Protected void Application_Start (object sender, EventArgs e ){
RouteTable. Routes. MapPageRoute (
"TestRoute", "Search/{ProductName }","~ /WebForm1.aspx ");
}
 

 

After writing Global. asax, when users type in the URL column:

Http: // localhost: 1031/Search/AK47

The webpage (Application master permission) will be directed to the WebForm1.aspx page, on which the ProductName "AK47" parameter can be obtained in the following way 』:

View plaincopy to clipboardprint?
Protected void Page_Load (object sender, EventArgs e ){
Response. Write ("Searching Product Name:" +
Page. RouteData. Values ["ProductName"]);
}
Protected void Page_Load (object sender, EventArgs e ){
Response. Write ("Searching Product Name:" +
Page. RouteData. Values ["ProductName"]);
}

 

This design method is indeed much more convenient and easy. Don't underestimate this mechanism, which makes it possible for us to develop large Web applications. In combination with the ASP. NET 4 in DynamicData technology, we can easily develop a single. the aspx web page (a program) allows you to maintain different data tables in the backend Schema. Unlike ASP. in the era of NET 2.0, if a backend database has many data tables to process, we have to create an independent one for each data table. aspx maintenance page, even if each. the behavior on the aspx web page is almost the same as the program code logic (CRUD ).

What's more interesting is that, in combination with the popularity of the URL Routing mechanism, even the DataSource control we used to be familiar with has added a RouteParameter. Now ASP. NET 4.0 Web Forms fully supports the URL Routing Mechanism:

 

 

View plaincopy to clipboardprint?
<Asp: LinqDataSource ID = "LinqDataSource1" runat = "server"
ContextTypeName = "UrlRouting. DataClasses1DataContext" EntityTypeName = ""
TableName = "Customers" Where = "CompanyName = @ CompanyName">
<WhereParameters>
<Asp: RouteParameter Name = "CompanyName" RouteKey = "CompanyName" Type = "String"/>
</WhereParameters>
</Asp: LinqDataSource>
<Asp: LinqDataSource ID = "LinqDataSource1" runat = "server"
ContextTypeName = "UrlRouting. DataClasses1DataContext" EntityTypeName = ""
TableName = "Customers" Where = "CompanyName = @ CompanyName">
<WhereParameters>
<Asp: RouteParameter Name = "CompanyName" RouteKey = "CompanyName" Type = "String"/>
</WhereParameters>
</Asp: LinqDataSource>
 

You will find that through the above syntax, we can let LinqDataSource directly reference the parameter values in URL Routing, similar to the previous QueryStringParameter, it is quite convenient and easy to use.