Is NancyFx reverse routing like ASP.NET MVC supported?

Question

ASP.NET MVC allow very usable way of generating stongly typed URL like:

<a href="@(Url.Action<AccountSettingsController>(c => c.BusinessInfo()))">Business info</a>

or even:

<a href="@(Url.Action<SomeOtherController>(c => c.SomeActionMethod(id, paramX, paramY)))">Business info</a>

Using simple custom URL helper:

public static string Action<TController>(
    this UrlHelper urlHelper,
    Expression<Action<TController>> action,
    string fragment = null
) where TController : BaseController
{
    var routeValues = InternalExpressionHelper.GetRouteValuesFromExpression(action);
    var url = UrlHelper.GenerateUrl(
            routeName: null,
            actionName: null,
            controllerName: null,
            protocol: null,
            hostName: null,
            fragment: fragment,
            routeValues: routeValues,
            routeCollection: urlHelper.RouteCollection,
            requestContext: urlHelper.RequestContext,
            includeImplicitMvcValues: true
        );
    return url;
}

It allows changing URL mapping in one place (RouteConfig) and any Controllers and Actions re-factoring doesn't mean you need to go and update each link.

I like NancyFx for it's simplicity and good IoC out of the box, but what i'm not sure why NanxyFx doesn't have support of reverse-routing (generating URL based on the action name) so it would be possible to create some static-typing helper for it.

Any ideas how to implement it in NancyFx or why if it's not possible to do, then why?

Answer 1

Routes are not named in Nancy so there's currently no way to implement such a feature.

But if you ever find yourself changing routes then I think you have a much bigger issue to begin with, personally this awesome feature (or lack of in your current case) has made me think more about what I'm making my routes, and so I now rarely, if ever, need to change my routes.

If I do need to rename a route, Find All makes it pretty quick to fix.

Answer 2

The accepted answer used to be right, but now there's Linker.

It doesn't do the expression parsing out of the box but it basically pulls parameters from property name-value pairs (like a RouteValueDictionary) so adding support for extracting the parameters from an expression tree shouldn't be too hard.