ASP.NET MVC Preview 5: is lambda-based route resolution still a possibility?
Phil Haack has just written about the new ActionNameAttribute in ASP.NET MVC Preview 5.
Initially, i was excited, however at the end of his post he claims that this “feature” is related to the reluctance of the MVC team to produce/support helpers “such as Url<T>(…), that use an expression to define the URL of an action”.
If i had a choice, i’d pick lambda-based resolution of action methods into routes over the ability to pseudo-name my controller action methods, and here’s why.
If i cannot do something like this in a View:
string incomingRoute = Html.ResolveRoute<ProductsController>(p => p.Show(someProductID));
then i am back to hard-coding string literals into my views, and what happens when i want to refactor my ProductsController.Show(…) method into ProductsController.Detail(…) or something else?
My unit tests all pass but suddenly, silently, my view is broken.
But wait…
So my view won’t acutally break because even though the method name has changed the route name (string-literal in an ActionName attribute) has not. Clever.
Now the consequence seems to be that while i can refactor my controller method names at will without breaking my routes, how do i refactor my routes? run a find-and-replace on string literals? I thought that lambdas took us past that paradigm.
I want to see string literals in one place; my route table setup. Everywhere else should use a code reference to describe the code i want to run and the helpers should lookup the code in the route table to find the outbound URL that will point to that code.
I wonder why the MVC team chose to abstract the action names into string literals instead of factoring the string literals out of the routing?