After playing with MS MVC for a little bit, and looking at routing extensively I have compiled a list of good things and things that need some improvement. The team has already said they will be doing work with routing, I am looking forward to seeing what they come up with.
What’s Good with MS MVC Routing?
Not Bound Explicitly To Controllers and Actions
An innovative approach to routing was not forcing the controller and action to be bound to the route. Instead they introduced two special parameters [controller] and [action] to indirectly bind the request. This drastically reduces the number of routes your application needs and means you do not have to register a route for every new controller.
Validation
Validation separates the url from matching on the parameters. It allows for full blown regular expressions without dirtying up the url and making it more difficult to generate urls from the routes. Hammett ran into this issue with his new routing module for monorail when he offered a straight regex rule. There was no way to pull parameters out of it.
Route Handlers
A very simple way to extend route resolution on incoming requests. Its not complicated and it gives you access to everything you need to do custom matching. I wish we could get something like that for generating urls.
Restful
Not much more to say hear that hasn’t already been said. This engine does make writing restful urls a breeze.
Testing
Thank you for making my routes so easy to test. I now have confidence that everything is working without having to fire up IIS and a browser to test by hand.
What’s Not So Good with MS MVC Routing?
No Duplicate Controller Names?
I can’t have two controllers in different namespaces with the same name?
Solution
Phil said they are fixing this. I would hope I could specify a Controller parameter either as a Type or a String where the string could be the full name of the controller. I would also maybe like this to be addressed with Areas… maybe.
Areas Where Are You?
There is no out of the box support for Areas. An area is simply a partition for your application. The most common one I can think of is http://localhost/admin/[controller] for separating all of your admin stuff from regular url’s.
Another scenario would be dropping in secondary applications, like a forum, blog, photo gallery, etc. Those will probably need to be defined under some Area.
Workarounds
RouteTable.Routes.Add(new Route
{
Url = “admin/[controller]/[action]“,
Defaults = new
{
Controller = “Admin“,
Action = “Index”
},
Validation = new
{
Controller = “Admin|Users|Categories”
},
RouteHandler = typeof(MvcRouteHandler)
});
What we did above is hard code are “admin” area and then set a Validation regular expression on Controller. Now only the controllers listed will be accessible via those urls, and when generating a url it will have the correct prefix of “admin/” in the path.
What sucks about that? Every time I add a new controller that should be an admin controller I have to modify the regular expression. BTW, that regex is not case insensitive like the url.
Potential Solutions
- Allow a convention where the namespace dictates the area.
- Add an AreaAttribute similar to Monorail.
I like having the option of number 1, but I don’t want to be forced to this. It makes my urls feel to tightly coupled to my code. Its not a bad default convention as I am sure it will work the vast majority of the time.
Number 2 just doesn’t sit right with me but it seems like a decent option as well. The area has to come from somewhere, right?
One thing is for sure, there needs to be some type of Area parameter that is respected by the RouteCollection and based on the current implementation it looks like it would be very difficult for it to support areas deeper than 1 level. By default it is splitting on the “/” so an area covering “admin/maintenance” would be difficult to use with a single Area parameter.
Maybe it could support arrays which could get interesting…
[area]/[area]/[area]/[controller]/[action]
Defaults = new { Area = "admin/maintenance/daily" }
Validation = new { Area = "admin/maintenance/daily" }
Are We Really Blocking and Locking?
Reflecting over the code of the RouteCollection we can see that when an operation is performed like GetRouteData or GetUrl then the routes are locked until the proper route is matched. Every request coming into your application is going to call GetRouteData and every link you render in your views is going to call GetUrl. What does this mean. It means when a request comes in it locks the routes searching for a match. When a new request comes in on a separate thread it calls GetRouteData too and sits and waits until the first request found a match before it can proceed. And all the blocking happens for every link that you are rendering in your views too. Most pages will have 10 - 20 links, that’s lot of blocking, idle time, and context switches for the OS.
Solution
Don’t lock, period. Adding routes should go into a temp route collection. Add explicit methods for Build() or Rebuild() which can perform an atomic assignment operation on the temp routes to the routes in use. Can some kind of error happen if routes are switch in the middle of processing a request? Yes. What are the odds? Slim. If dynamically altering routes is something that my application requires, without restarting it, then let me handle that. Its an edge case.
If you have to lock, think about using a lock free collection, or use Reader/Writer locks as the number of reads is going to demolish the number of writes. Locking is just way too expensive to do on every request and every link render.
Why is Validation Case Sensitive?
Urls should be case insensitive. If I want to validate parameters using a regular expression those should be case insensitive to. Please don’t make me write Validation expression like: @”[eE][dD][iI][tT]” to match any combination of the string “Edit”.
Why is Validation Not Compiled?
Every request coming in is going to call GetRouteData, does it not make sense to compile my Validation expressions so they do not need to parsed every time they are evaluated?
Solution
if (!Regex.IsMatch(input, pattern))
{
return false;
}
to
foreach(Regex validator in route.Validators)
{
//…
if(!validator.IsMatch(input))
{
return false;
}
//…
}
Where is the Extensibility?
No, not this extensibility, well maybe, give me the option please.
There are a number of edge cases popping up on blogs, comments, and forum posts.
- What do I do if I need a different sub/domain?
- What do I do if I need to redirect to a secure url from an insecure one?
- What do I do if I need an absolute url instead of a relative one?
- What do I do if I need to redirect to a non-standard port for https?
While the MVCRouteHandler is extendable the Route is not, nor is the RouteCollection. We need a way to override the matching AND url generating for specific rules.
Potential Solution
The RouteCollection looks a little heavy. I think it can delegate some of its responsibility to other services whose implementations can be swapped out. I also think it would be prudent to give us some interfaces and factories. Just overriding the GetRouteData and GetUrl is not enough. It would be great to have the ability to create our own RouteCollection so we could implement different algorithms for collecting and enumerating the routes to find a match?
Summary
All in all I am very pleased with routing in the first CTP. IMHO it is better than Monorail routing right now. It does need some pieces re-thought, re-factored, and de-debugged, but if it were perfect it wouldn’t be CTP and I wouldn’t be writing this.
Please let me know what I am missing and how crazy some of my solutions are.
+1 To the MS-MVC team, they are off to a great start.
Tags:
.net,
aspnetmvc,
routing
