asp.net-mvc - 为什么 MVC Controller 的类名必须有尾随的 'Controller' 约定？

Question

我发现 MVC 无法识别 Controller ，除非它在类名后面附加了“ Controller ”，这很荒谬。 This answer提到ControllerDescriptor和 ControllerTypeCache作为 MVC 中设置此约定的两个地方。

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

已公开

不抽象

实现 IController

以 "Controller" 结尾

有人知道这是什么原因吗？毕竟所有 Controller 都可能在一个实际的 MVC 项目中，在一个名为“Controllers”的文件夹中，然后简单地双击该文件将显示该类继承了 Controller .

对我来说似乎很傻 - 但我想知道是否有 实际 他们这样做的原因。

编辑

刚看到 this blog post菲尔·哈克(Phil Haack)从昨天开始讨论这个大会的决定——他和我的想法一样——可能有点毫无意义!

Answer 1

定制 Controller 工厂

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

可能是 Visual Studio？

尽管它可能与 Visual Studio 有关。类似于属性类。也许 Visual Studio 不会为不以 Controller 结尾的类提供额外的上下文菜单项。当处于 Controller 操作中时，您可以轻松导航(或创建)到匹配的 View 。

约定很好

所以say the experts我同意。 .net 框架中还有其他类似的约定，但人们不会提示它们。

想想收藏 , 字典 , 属性 , 列表 以及其他类型也使用类似后缀而没有特殊原因。无论哪种方式它们都可以工作，但它们的用户(开发人员)更容易识别它们，他们本能地知道它们应该如何工作以及何时使用它们。

根据 Asp.net MVC 团队的类型冲突

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

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