Jul 22, 2012 at 9:08 AM
Edited Jul 22, 2012 at 9:47 AM
OK, I am working on a different approach to routing (implementing hierarchical routing) and I have inherited from HttpRoute and overriden a few things.
Now when I add my route to GlobalConfiguration.Configuration.Routes, I was surprised that my behaviour does not get triggered. After some head-scratching, if found this in HostedHttpRouteCollection:
public override void Add(string name, IHttpRoute route)
So whatever implementation I have for my route, it is being ignored since HostedHttpRouteCollection turns it into the route it likes!
First of all, a collection is not expected to just suddenly covert the value being added. This is not the way all collections AFAIK work.
On the other hand, This line in .ToRoute() defeats the object oriented inheritance in routing:
HostedHttpRoute hostedHttpRoute = httpRoute as HostedHttpRoute;
if (hostedHttpRoute != null)
httpRoute parameter passed in here is of type IHttpRoute. So unless it is a HostedHttpRoute, it will be turned into one and with HostedHttpRoute an internal class, I have no chance of overriding behaviour! Again this to me, defeats the OO approach when
I have to check the type of the inherited type.
It looks to me that you guys have done a great job bringing MVC and Web API routing together - which I am sure was not easy at all. This seemed to have resulted in some compromises here and there and with Web API routing needing some new requirements, solutions
was to translate traditional routing into Web API routing which causes inherited behaviours being ignored.
Reality is IHttpRoute does not define not just a data bag. It expresses important overridable behaviours.
This implementation keeps the data at the time of onversion but throws away the behaviour. So to me solution is to use
composition rather than conversion, to add new stuff while keeping the old behaviour. I can work on this and send a Pull Request if you happy.
So it is at all possible to have my alternative routing logic plugged in?