MSDN Magazine - January 2009 - (Page 103)

ScoTT AllEN ExtrEmE ASP.NEt Routing With ASP .NET Web Forms Service Pack 1 for the Microsoft .NET Framework 3.5 introduced a routing engine to the ASP.NET runtime. The routing engine can decouple the URL in an incoming HTTP request from the physical Web Form that responds to the request, allowing you to build friendly URLs for your Web applications. Although you’ve been able to use friendly URLs in previous versions of ASP.NET, the routing engine provides an easier, cleaner, and more testable approach. The routing engine began as a part of the ASP.NET Model View Controller (MVC) framework, which is in a preview stage as of this writing. However, Microsoft packaged the routing logic into the System.Web.Routing assembly and released the assembly with SP1. The assembly currently provides routing for Web sites using ASP.NET Dynamic Data features (which were also released with SP1), but in this column I will demonstrate how to use the routing functionality with ASP.NET Web Forms. With the routing engine, you can build friendly URls for your Web apps. users, and includes important keywords for search engines to see. What Is Routing? Imagine you have an ASP.NET Web Form named RecipeDisplay.aspx, and this form lives inside a folder named Web Forms. The classic approach to viewing a recipe with this Web Form is to build a URL pointing to the physical location of the form and encode some data into the query string to tell the Web Form which recipe to display. The end of such a URL might look like the following: /WebForms/RecipeDisplay.aspx?id=5, where the number 5 represents a primary key value in a database table full of recipes. Routing is fundamentally about decomposing a URL endpoint into parameters and then using those parameters to steer the HTTP request processing to a specific component. Let’s take the URL /recipe/5 as an example. With the proper routing configuration, you can still respond to this URL with the Web Form RecipeDisplay.aspx. The URL no longer represents a physical path. Instead, the word recipe represents a parameter that the routing engine can use to locate a component for processing recipe requests. The number 5 represents a second parameter that you’ll need during processing to display a specific recipe. Instead of encoding database keys into the URL, a better idea might be to use a URL like /recipe/tacos. This URL not only includes enough parameters to display a specific recipe, but is also human readable, reveals its intent to end In ASP.NET, using a URL ending with /recipe/ tacos traditionally required one to work with a URL rewriting scheme. For detailed information on URL rewriting, see Scott Mitchell’s definitive article “URL Rewriting in ASP.NET” (available at msdn.microsoft.com/library/ms972974). The article describes the common implementation of URL rewriting in ASP.NET using an HTTP module and the static RewritePath method of the HttpContext class. Scott’s article also details the benefits of friendly, hackable URLs. Those of you who have used the RewritePath API in the past are probably familiar with some of the quirks and weaknesses in the rewriting approach. The primary problem with RewritePath is how the method changes the virtual path used during the processing of a request. With URL rewriting, you needed to fix up the postback destination of each Web Form (often by rewriting the URL a second time during the request) to avoid postbacks to the internal, rewritten URL. In addition, most developers would implement URL rewriting as a one-way translation because there was no easy mechanism to let the URL rewriting logic work in two directions. For example, it was easy to give the URL rewriting logic a public-facing URL and have the logic return the internal URL of a Web Form. It was difficult to give the rewriting logic the internal URL of a Web Form and have it return the public URL required to reach the form. The latter is useful when generating hyperlinks to other Web Forms that hide behind rewritten URLs. As you’ll see in the rest of this column, the URL routing engine circumvents these problems. A Brief History of URL Rewriting Of Routes and Route Handlers There are three fundamental players in the URL routing engine: routes, route handlers, and the routing module. A route associates a URL with a route handler. An instance of the Route class from the System.Web.Routing namespace represents a route during run Send your questions and comments to xtrmasp@microsoft.com. Code download at code.msdn.microsoft.com/mag200901Extreme. January 2009 103 http://www.ASP.NET http://msdn.microsoft.com/library/ms972974 http://code.msdn.microsoft.com/mag200901Extreme

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.