Why is using named routes for generating outbound URLs a violation of Separation of Concerns?

Question

https://stackoverflow.com/questions/98734/what-is-separation-of-concerns

In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors. Progress towards SoC is traditionally achieved through modularity and encapsulation, with the help of information hiding.

From Pro Asp.Net MVC 4 book ( page 375 ):

The problem with relying on route names to generate outgoing URLs ( @Html.RouteLink("Click me", "MyOtherRoute","Index", "Customer") is that doing so breaks through the separation of concerns that is so central to the MVC design pattern. When generating a link or a URL in a view or action method, we want to focus on the action and controller that the user will be directed to, not the format of the URL that will be used. By bringing knowledge of the different routes into the views or controllers, we are creating dependencies that we would prefer to avoid.

a) I understand that we create a dependency ( between action method/view and a routing configuration module ) by having Html.RouteLink ( called within action method or view ) specifying the name of the route we want to use.

But is introducing such a dependency already considered a violation of SoC? Namely, even though we created a dependency between the two modules, we haven't actually introduced any additional functionality/concern into either of the modules ( the definition of SoC implies that violation of SoC occurs when new functionality/concern is introduced into a module )

b) Anyhow, I don't understand how will simply generating an URL ( within action method/view ) by specifying a named route bring focus to the format of the URL?

Thank you

Answer 1

I think what the Pro ASP.NET MVC book means is that, by referring to a route by name you have now created a dependency on a particular route definition, rather than relying strictly on the action and controller that will be called.

The route is what determines the shape of the URL. If you create a link by using a route name, you are literally saying "I want the URL to be this shape," rather than saying "I want the URL to invoke this functionality" and letting the route engine decide which route is most appropriate.

Whether or not this makes sense in your particular application ultimately depends on your needs. Using a named route creates a level of indirection which allows you to change both the shape of the URL, and the controller/method that gets called, by merely changing the entry in the route table.

As to the coupling aspect, using a named route does tightly-couple the links to that specific route because no other route would be eligible, and because it requires the view to have knowledge of that specific route. Whether that is a problem or not, again, depends on your needs. If that coupling is a desirable feature, it doesn't really matter whether it is "tight" or not according to someone else's opinion.

Answer 2

It doesn't violate the SOC principle; the author is wrong.

Named routes typically encapsulate the controller and the action as well as URL, which frees the view from having to know them. Used this way they actually promote separation of concerns as the view is freed from knowing the name of the controller and action.

Here is an example:

routes.MapRoute(name: "SignUpPromotion", 
                url: "some/url", 
                new { controller = "SignUp", action= "Promotion" });

By using Html.RouteLink("SignUpPromotion"), I've freed the view from having to know the names of the controller and the action. I could rename the action or even move it to a new controller without affecting the view or changing the URL.