Why do MVC controllers have to have the trailing 'Controller' convention on their class name?

Question

I find it ridiculous that MVC doesn\'t recognize a controller unless it has \'Controller\' appended to the class name. This answer mentions the ControllerDescriptor

Answer 1

Custom controller factory

You can always provide a custom controller factory that will resolve these classes differently. And I do agree that controllers need no Controller type name appending because after all they're just like any other class. Their OOP ancestor type defines them as controllers anyway (IController, Controller...)

Visual Studio maybe?

Although it may have something to do with Visual Studio. Similar to Attribute classes. Maybe Visual Studio wouldn't provide additional context menu items to classes that don't end with Controller. When being in controller action you can easily navigate (or create) to the matching view.

Conventions are good

So say the experts and I do agree. There are other conventions like these in .net framework as well but people don't complain about them.

Think of collections, dictionaries, attributes, lists and other types that also use similar suffixes without particular reason. They'd work either way, but they're much easier recognisable by their users - developers - who instinctively know how they should work and when to use them.

Type clashes as per Asp.net MVC team

Imagine having a ProductController that likely handles Product application model entity instances. By not having the controller naming convention, we'd have two types with the same name hence would always have to provide namespaces to distinguish between the two. But because we do have this convention this is not necessary and no type clashes occur.

public class ProductController : Controller
{
    public ActionResult Index()
    {
        // we'd have to distinguish this Product type here
        IEnumerable<Product> result = GetProducts();
        return View(result);
    }
    ...
}

Answer 2

Yes conventions are good, but I don't think this is a matter of convention. It's a matter of selecting a good name from the solution domain for the pattern one is using.

For example, if the UX of dealing with products involves a list then you can simply call the controller ProductList and it need not be confused with List. As human beings we easily disambiguate everyday based on context and naming in software should be no exception. Now the role of a controller is to coordinate. In the case of our ProductList. It will coordinate actions like ProductList.sort(byField), ProductList.delete(product).

As far as taking advantage of the the concept of convention over configuration, one can do that at a meta-level. In .Net one could use an attribute to identify a controller or a model.

What's the big deal? Stating the pattern in the name invites lazy naming and thus lazy modeling. A name is not just a name, it selects a concept that you're using to model the solution domain whose meaning drives decisions about what code represents that concept and what other code that code is coupled to. The more generic and/or ambiguous your names are the more you invite your design to be extended and changed in ways that are harder to maintain.

Answer 3

First 2 are needed so that mvc can instantiate the controller, 3rd is needed so that mvc knows how to use the controller (to call Execute method), and 4th I guess is simply to find the type faster.