Using ASP.net Web Form routing

The Microsoft. NET Framework 3.5 Service Pack 1 introduces the routing engine in the ASP.net runtime. The routing engine can detach the URL in the request from the actual Web form in response to the incoming HTTP request, enabling you to build a friendly URL for the Web application. Although friendly URLs have been used in previous versions of ASP.net, the routing engine provides a simpler, clearer, and easier way to test.

The routing engine was originally part of the ASP.net Model View Controller (MVC) framework, which is still in the staging phase when writing this article. However, Microsoft encapsulates the routing logic into the System.Web.Routing assembly and publishes the Assembly with SP1. The assembly currently uses the ASP.net Dynamic Data feature, which is also published with SP1, to provide routing for the site, but in this column, I'll explain how to use the routing feature by ASP.net Web forms.

What is routing?

Suppose you have a asp.net Web form named Recipedisplay.aspx, which is located in a folder called Web Forms. When viewing a scenario using this Web form, the traditional method is to build a URL that points to the actual location of the form and embed some data in the query string by encoding to tell the scenario to be displayed by the Web form. The end of such a URL may be as follows:/webforms/recipedisplay.aspx?id=5, where the number 5 represents the primary key value in a database table full of scenarios.

Routing essentially decomposes a URL endpoint into multiple parameters, and then uses these parameters to boot HTTP request processing to a specific component. Let's take URL/RECIPE/5 as an example. With the correct routing configuration, you can still use Web forms recipedisplay.aspx to respond to this URL.

At this point the URL no longer represents the actual path. The word recipe changes to represent a parameter that the routing engine can use to locate the component that handles the recipe request. The number 5 represents the second parameter, which is used to display a particular recipe during processing. It is not advisable to embed the database keyword in the URL by encoding, preferably using a/recipe/tacos URL. This URL not only includes enough parameters to display a specific recipe, but is also very easy for people to read and understand, it can reveal their intentions for end users, and includes some important keywords for search engine use.

A brief history of URL rewriting

In ASP.net, when you use a URL that ends with/recipe/tacos, someone traditionally needs to handle the URL rewrite schema. For more information about URL rewriting, see the authoritative article in Scott Mitchell, "Perform URL rewriting in asp.net." This article describes a common way to rewrite URLs using the static RewritePath methods of HTTP modules and HttpContext classes in asp.net. Scott's article also details the advantages of a friendly and easily modified URL.

Users who have used the RewritePath API in the past may be very clear about some of the quirks and drawbacks of rewriting methods. The main problem facing RewritePath is how the method changes the virtual path used during the processing of the request. When you use URL rewriting, you need to set the postback target for each WEB form (typically implemented by rewriting the URL again during the request) to avoid a postback going to the internally overridden URL.

In addition, most developers adopt a one-way conversion pattern when implementing URL rewriting, because the URL rewrite logic works in both directions without any simple mechanism. For example, it is easy to give the URL rewrite logic a public-facing URL and make the logic return the internal URL of the Web form. However, it is difficult to give the internal URL of a Web form an overriding logic and return it to the public URL required to enter the form. The latter is useful when generating hyperlinks to other Web forms that are hidden in the overridden URL. The remainder of this column describes how the URL routing engine resolves these issues.

Figure 1 Routing, routing handlers, and routing modules