Is hardcoding controller, view and action names in MVC good practice?

Question

When looking over MVC code you will very often run into code snippets like below:

return RedirectToAction("Index");

<li>@Html.ActionLink("Books", "Index", "Books")</li>

where controller names, controller action names or view names as provided as hard-coded strings. This is a common practice, but is it a good practice? After all if you rename controller, and forget to rename one of many references you would get a run-time error, rather than much more preferred compile-time error.

You could likely alleviate that issue by adding static Name property to your BaseController, and then use code as follows (action names would be slightly more difficult to accomplish).

<li>@Html.ActionLink("Books", "Index", BooksController.Name)</li>

So is this hard-coding something that should be considered as a lesser evil (over not using MVC). Or did people developed some practices to work around it?

Answer 1

You're looking for T4MVC, which generates strongly typed classes of string constants.

Answer 2

Instinctively we know that string literals are a bad thing, so your gut instinct to make "Books" a constant would normally be good. The idea is to put the string in a single location, so when you need to change "Books" to "Products", say, you only have to change it in one place.

However, in doing so, you're messing up the very tools that will help you out. I just used Resharper to rename "HomeController" to "BananaController", and it automatically updated every reference of @Html.ActionLink(... "Home" ..) to @Html.ActionLink(... "Banana" ..)

I don't know if VS will do that without Resharper. VS is getting better at refactoring every year I'm told, but I don't actually work with anyone who doesn't have Resharper...