为什么MVC控制器必须在其类名上具有尾随的"Controller"约定？

Question

我发现MVC无法识别控制器,除非它在类名附加了"Controller",我觉得很荒谬.这个答案提到的ControllerDescriptor和ControllerTypeCache作为MVC中的两个地方此惯例设立.

我的问题是为什么？这显然不是在配置事物的约定,如IsControllerType在ControllerTypeCache检查该类:

• 是公开的
• 不是抽象的
• Implementes IController
• 以..结束 "Controller"

有人知道这个的原因吗？在所有控制器可能都在一个实际的MVC项目之后,在名为"Controllers"的文件夹中,只需双击该文件就会向我们显示该类继承Controller.

对我来说只是愚蠢 - 但我想知道他们是否有这样做的实际原因.

编辑

刚刚看过菲尔·哈克(Phil Haack)昨天发表的这篇博文,他讨论了这个大会的决定 - 他对我有同样的想法 - 可能有点无意义!

Answer 1

定制控制器工厂

您始终可以提供自定义控制器工厂,以不同方式解析这些类.我同意控制器不需要附加控制器类型名称,因为毕竟它们就像任何其他类一样.他们的OOP祖先类型无论如何都将它们定义为控制器(IController,Controller...)

Visual Studio可能吗？

虽然它可能与Visual Studio有关.与属性类相似.也许Visual Studio不会向不以Controller结尾的类提供额外的上下文菜单项.在控制器操作中,您可以轻松导航(或创建)到匹配的视图.

公约很好

所以说专家,我同意.在.net框架中还有其他类似的约定,但人们不会抱怨它们.

考虑集合,字典,属性,列表以及其他类型的后缀,没有特殊原因.他们的工作方式不同,但他们的用户 - 开发人员 - 更容易识别他们本能地知道他们应该如何工作以及何时使用它们.

根据Asp.net MVC团队输入冲突

想象一下,有ProductController可能处理Product应用程序模型实体实例.由于没有控制器命名约定,我们有两个具有相同名称的类型,因此总是必须提供名称空间来区分这两者.但是因为我们确实有这个约定,所以这不是必需的,也不会发生类型冲突.

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