Also read: MVC 6 vNext Web Application Guide Basic Overview
Routings
Hello Guys. it's me again with the vNext Guides (the person with the guides: D) and this is the Guide series that the main idea is to provide a short overview of various aspects of MVC 6 VNEXT that are new to the MVC Architecture.
In this tutorial our main focus will be
Routing systems and most importantly the things that have been changed in the way that MVC 6 is routing.
As you all know, in the past the routing system was implemented as an integrated feature in ASP MVC (in the early beta) and afterwards was separated into its own assembly
System.Web.Routing.However after some time Microsoft introduced to the developer's community Web APIs and as we know the Web API have its own routing mechanism that is totally different from the MVC one and as developers the idea to have two separated routings for technologies that are sharing the same framework is giving us chills.
The other problem with the two routings that developers have encountered is the issue of when they need to arrange two types of routings in their applications (if they want to use both MVC and the Web API) that can lead to many troubles in one more complex solution.
Finally …. Unification
In MVC vNext Microsoft has unified both the MVC and Web API routings into one unified Routing class
Microsoft.ASPNET.Routing. This class is used from all .Net framework web applications and as you know (from my last article duuh: D) Microsoft has started to use many more Nugget packages instead of DLLs and one of the packages is the routing class. He is stored in the following address:
https://github.com/aspnet/RoutingRouting improvements
One of the coolest new things is the routing improvements. There are two major improvements (for now) that have made the developer's life easier:
- Unhandled requests: If there is a request that cannot be handled by the route then the routing system will try to match the request with the next route in the routes collection.
- DI Constrains: The Routing system now can use Dependency Injection (DI) for a much more efficient look over the available Actions.
Routing as middleware
The next cool thing in the VNext over which I want to talk about is the routings are separated as middleware providing the flexibility to compose routings with other middleware components like SignalR, error pages and others.
Changes in the Route constrains
Until now if we wanted to set some kind of constraint in the routes (such as a regex constraint) then we would need to do something similar to:
constraints: new { bookId = @"\d+" });
That will match the digits passed to the bookId, they need to be in the range (0-9).
However in the vNEXT Microsoft has facilitated us by providing inline route constraints that simplify the preceding constraint. It is in the following form:
"{parameter:constraint} "
So by using this format our constraint will look like the following:
“Action/{bookid:int} ”
The full list of the constraints that can be used in the routings are as follows (thanks to the MSDN):
| Constraint |
Description |
Example Template |
| alpha |
Matches uppercase or lowercase Latin alphabet characters (a-z, A-Z) |
" Action /{ bookid:alpha} " |
| int |
Matches a Signed 32-bit integer value. |
" Action /{ bookid:int} " |
| long |
Matches a Signed 64-bit integer value. |
" Action /{ bookid:long} " |
| minlength |
Matches a string with a minimum length. |
" Action /{ bookid:minlength(10)} " |
| Regex |
Matches a regular expression. |
" Action /{ bookid:regex(^\\d{4}$)} " |
Optional parameters and default values
Finally something that I have been waiting for a long time is, in vNext routing you have the possibility to set an optional parameter by setting a question mark “?” after the constraint as in the following:
" Action /{ bookid:int?} "
And if you want to set a default value for the specified parameter then the only action that is needed to be done is to set the default value after the constraint:
" Action /{ bookid:int=1} "
And at the end…
In conclusion I want to say that ASP.NET is one of the greatest technologies available for us developers, not because of it's manufacturer, but because of the flexibility of the framework and willingness of the .Net Team to change the very core of their product so they can provide a better framework and a better development experience.