7

In ASP.NET MVC, we're required to use the suffix "Controller" for all controllers. This seems unnecessarily restrictive - is there a technical reason for it?

I'm mostly just curious, but can see situations where more flexible naming rules could improve code organization. Couldn't the discovery of possible controller classes be easily made using reflection to search for Controller derived classes? Or require that controller classes be marked with a ControllerAttribute?

Shog9
  • 156,901
  • 35
  • 231
  • 235
Edwin Jarvis
  • 5,980
  • 6
  • 36
  • 41

2 Answers2

14

The MVC community is heavily influenced by Ruby on Rails, which values "convention over configuration". By just naming things consistently, the application can run with zero configuration.

Jacob Carpenter
  • 4,134
  • 1
  • 29
  • 30
4

One of the benefits of this convention is that it's common to have a URL segment, controller, and a model class all have the same name.

URL: /product/ Controller: Product : Controller Model: Product

This would cause a naming conflict. So we made a convention to have controller names suffixed with "Controller" to avoid this conflict. However, you can override this behavior via our extensibility APIs.

Haacked
  • 58,045
  • 14
  • 90
  • 114
  • Actually Phil... By REST those URL segments should name collections which means that controllers are usually plural as in `ProductsController` (/products/1) while model entity is singular as `Product` because collection displaying views will use model `IEnumerable`. So there would be no clashes anyway. But convention is good, because it's used elswhere as well (without people complaining) as in attributes, collections, dictionaries, lists etc. These types also *conventionally* use suffixes. For development usability reasons of course. – Robert Koritnik Jul 19 '12 at 09:34