asp.net 4 's Web Forms full support URL routing mechanism

The most exciting of ASP.net 4 Web Forms is the full support of the URL routing mechanism. In the past ASP.net 3.5 SP1, Web forms have more or less supported the URL routing mechanism, which gives us more flexibility in the rendering and use of Web sites.

In the past, we used to asp.net in the following way: http://myWebSite/EditProduct.aspx?Id=1

But in recent years RESTful Web sites (or rest Web services) have sprung up, and you often see the way URLs are rendered: Http://myWebSite/Product/Edit/XBOX

The above URLs have some benefits, first of all, the URL can be more explicit to express the function to be rendered, or to the behavior of the backend application, and secondly, the URL above is not corresponding to the back-end of an entity file (. aspx.cs), but through the routing mechanism to transfer, Therefore, compared with the previous web site has a higher security.

In other words, under such an architecture, ASP. NET application URL is no longer just a path to an entity file, but it can be used to express the functionality to be performed. As for the actual execution of the program code or the rendering results of the Web page, it is not necessarily the site to point to the entity page. This also allows us to develop applications with greater flexibility, such as the General blog site URL may be "http://blog/studyhost", since most blog sites can open to many people to apply for, of course, every user has a similar "http://blog/ Requester id "such a URL. Of course, the back end of the asp.net should be the same set of procedures to deal with, in the past ASP.net applications, we have to take a hard time to allow the site to accept such a Web site design (change the parameters from QueryString to rest style), and now, through the URL The routing mechanism will soon be easy to handle.

In addition, there is another obvious benefit, the rest-style URL: Http://myWebSite/Product/Edit/XBOX vs. http://myWebSite/EditProduct.aspx?Id=1

Compared to the traditional Web site is more easily by Google and other search engine query and retrieval, after all, the Xbox on the map site than the product id=1 easy to understand more easily. So how do we use this mechanism in ASP.net 4, you just need to use the Mappageroute method to easily specify the URL route through the newly added routes category, for example:

The following are the referenced contents: 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 Global.asax is so written, when the user types in the URL column: http://localhost:1031/Search/AK47

The Web page (application Master) will be directed to the WebForm1.aspx page, where the parameter ProductName "AK47" can be obtained in the following way:

The following are the referenced contents: 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 way of design, it is easy to easily many, do not underestimate such a mechanism, which allows us to develop large Web applications become possible, in line with the ASP.net 4 of the DynamicData technology we want to introduce later, We have been able to easily develop a single. aspx Web page (a program) that maintains a variety of data tables with different backend schemas. Unlike in the past ASP.net 2.0, if the back-end database has a lot of data tables to deal with, we almost have to create a separate. aspx maintenance page for each datasheet, even if the behavior on each. aspx Web page is almost exactly the same as the Code logic (CRUD).

More interestingly, with the popularization of the URL routing mechanism, even the datasource controls that we used to know have added a routeparameter to join the festivities, now ASP.net 4.0 Web forms can be said to be URL The routing mechanism fully supported:

The following are the referenced contents: 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 data query when the parameters used in the where condition, directly referencing the URL routing parameter values, similar to the past QueryStringParameter, quite convenient and easy to use.