Mit dem Release von Version 3.5 ServicePack 1 wird neben ASP.Net MVC nun auch “Standard” ASP.Net endlich Routing unterstützen. Was Routing ist, brauche ich an dieser Stelle wohl nicht mehr zu erklären :D. In der kommenden Version 4.0 wurden noch einige Neuerungen eingebaut und einige vorhandene Methoden refactord oder ersetzt. Hier eine kurze Übersicht zu Routing in ASP.Net 4.0 Webforms.
Routing Konfigurieren
Konfiguriert wird Routing in ASP.Net 4.0 analog zu ASP.Net MVC in der Applikationsklasse sprich Global.asax. Im Application_Start Event können beliebige Routen definiert werden, die dann zur Laufzeit angewendet werden.
Ein einfaches Beispiel ist das Routing für Blogeinträge. In der fiktiven Webanwendung sollen Blogeinträge über die Url
http://www.thorsten-hans.de/Entry/4711
verfügbar sein. Praktisch sieht die Url allerdings wie folgt aus
http://www.thorsten-hans.de/Entry.aspx?Id=4711
Der ASP.Net Engine bringt man dieses Routing ganze einfach so bei
1: System.Web.Routing.RouteTable.Routes.Add("BlogEntryRoute",
2: new System.Web.Routing.Route("Entry/{id}",
3: new System.Web.Routing.PageRouteHandler("~/Entry.aspx")));
So einfach kann auch in ASP.Net 4.0 Routing konfiguriert werden. Parameter in Routen werden wie in diesem Beispiel der ID Parameter in geschweiften Klammern {} angegeben.
Verwenden von Routingparametern in Webseiten
Die im Routing definierte ID ist ein Routingparameter, Routingparameter sind dynamische Bestandteile einer Route die variabel vom Anwender angegeben werden können. Die Definition des Parameters war sehr einfach, genau so straight ist der Zugriff auf den Parameter.
Es gibt in ASP.Net 4.0 drei Wege Routingparameter auszulesen
- Im Codebehind ( C# oder VB)
- Im Markup der Zielresource
- In einer Datenquelle
Abrufen von Routingparametern im Codebehind
Im Codebehind der Page Entry.aspx kann der ID Parameter dann so abgefragt werden
1: if(Page.RouteData.Values["id"]!=null)
2: this.labelBlogEntryId.Text = Page.RouteData.Values["id"].ToString();
Wichtig ist hierbei, den gewünschten Parameter aus der RouteData Collection zunächst auf null zu prüfen, dadurch kann eine ASP.Net Exception vermieden werden, wenn der Anwender nur die URL
http://www.thorsten-hans.de/Entry/ aufruft.
Abrufen von Routingparametern im Markup der Zielresource
Ganz nützlich ist auch die Möglichkeit die Routingparameter direkt im Markup verwenden zu können. So kann man zum Beispiel den Routingparameter ID an eine TextBox oder als SelectedValue einer DropDownList binden
1: <asp:DropDownList ID="DropDownListWhatEver"
2: runat="server" SelectedValue='<%$RouteValue:Id%>' />
Leider ist in der aktuellen Version von VisualStudio 2010 für die RouteValue Collection noch kein IntelliSense eingebunden, was die Verwendung im Markup noch angenehmer und schneller machen würde!
Abrufen von Routingparametern in Datenquellen
Die dritte Möglichkeit wie man Routingparameter in ASP.Net konsumieren kann, sind die *-DataSoruce Objekte. Hierbei wurde die ParameterCollection um den Parametertyp RouteParameter erweitert. Eine einfache SQL-DataSource sieht mit RouteParameter so aus
1: <asp:SqlDataSource ID="blogDataSource" runat="server"
2: SelectCommand="select * from blogentries where id=@id">
3: <SelectParameters>
4: <asp:RouteParameter Name="id"
5: DefaultValue="1" RouteKey="id" DbType="Int64" />
6: </SelectParameters>
7: </asp:SqlDataSource>
Wichtig ist beim RouteParameter die korrekte Angabe des RouteKey’s, der hier wieder auf den zuvor definierten Routingparameter ID verweist.
Fazit
Endlich! Endlich! Endlich! Mehr kann ich bis jetzt nicht dazu sagen, es wurde auch Zeit, dass man in ASP.Net Webforms auch ein schönes Routing OOB definieren kann. Auch die Verwendung der Routingparameter ist schön und durchgängig gelöst. Allerdings macht dieses Feature die Entscheidung zwischen ASP.Net Webforms und ASP.Net MVC nicht gerade einfacher :)