Routing rules are registered by adding Route instances into
the System.Web.Mvc.RouteTable's Routes collection.
The Route class defines a number of properties that you can
use to configure the mapping rules. You can set these properties using
either "traditional" .NET 2.0 property assignments:
Figure 5
Or by taking advantage of the new object initializer feature in the VS 2008 C# and VB compilers
to set the properties more tersely:
Figure 6
The "Url" property on the Route class defines the
Url matching rule that should be used to evaluate if a route rule applies to a
particular incoming request. It also defines how the URL should be tokenized
for parameters. Replaceable parameters within the URL are defined using a
[ParamName] syntax. As we'll see later, we aren't restricted to a fixed
set of "well known" parameter names - you can have any number of
arbitrary parameters you want within the URL. For example, I could use a
Url rule of "/Blogs/[Username]/Archive/[Year]/[Month]/[Day]/[Title]"
to tokenize incoming URLs to blog posts - and have the MVC framework
automatically parse and pass UserName, Year, Month, Day and Title parameters to
my Controller's action method.
The "Defaults" property on the Route class defines
a dictionary of default values to use in the event that the incoming URL
doesn't include one of the parameter values specified. For example, in
the above URL mapping examples we are defining two default URL parameter values
- one for "[action]" and one for "[id]". This means
that if a URL for /Products/ is received by the application, the routing system
will by default use "Index" as the name of the action on the
ProductsController to execute. Likewise, if /Products/List/ was
specified, then a null string value would be used for the "ID"
parameter.
The "RouteHandler" property on the Route class
defines the IRouteHandler instance that should be used to process the request
after the URL is tokenized and the appropriate routing rule to use is
determined. In the above examples we are indicating that we want to use
the System.Web.Mvc.MvcRounteHandler class to process the URLs we have
configured. The reason for this extra step is that we want to make sure
that the URL routing system can be used for both MVC and non-MVC
requests. Having this IRouteHandler interface means we will be able to
cleanly use it for non-MVC requests as well (such as standard WebForms, Astoria
REST support, etc).
There is also a "Validation" property on the Route
class that we'll look at a little later in this post. This property
allows us to specify pre-conditions that need to be met for a particular
routing rule to match. For example, we could indicate that a routing rule
should only apply for a specific HTTP verb (allowing us to easily map REST
commands), or we could use a regular expression on arguments to filter whether
a routing rule should match.
Note: In the first public MVC preview the Route class isn't
extensible (instead it is a data class). For the next preview release we
are looking to make it extensible and enable developers to add scenario
specific route classes (for example: a RestRoute sub-class) to cleanly add
additional semantics and functionality.
