asp.net-mvc – 为什么MVC控制器必须在其类名上具有尾随的’Controller’约定？

我觉得MVC无法识别控制器，除非它将“Controller”附加到类名。 This answer提到ControllerDescriptor和ControllerTypeCache作为MVC中两个设置此约定的地方。

我的问题是为什么这显然不是配置事物的约定，因为ControllerTypeCache中的IsControllerType会检查类：

>是公开的
>不抽象
>实现IController
>结束与“控制器”

有人知道这个的原因吗？所有控制器都可能在一个实际的MVC项目中，在名为“控制器”的文件夹中，并且简单的双击该文件将向我们显示该类继承了Controller。

对我来说似乎很傻 – 但是我想知道他们是否有实际的理由。

编辑

从昨天的Phil Haack刚刚看到this blog post，他讨论了这个公约的决定 – 他和我一样的心 – 可能有点无意义！

解决方法

自定义控制器工厂

您可以随时提供一个自定义控制器工厂，以便不同地解决这些类。我同意控制器不需要控制器类型名称追加，因为毕竟他们就像任何其他类。他们的OOP祖先类型将它们定义为控制器(IController，Controller …)

Visual Studio可能吗

虽然它可能与Visual Studio有关。类似于属性类。可能Visual Studio不会为不以Controller结尾的类提供附加的上下文菜单项。在控制器操作中，您可以轻松地导航(或创建)到匹配的视图。

公约是好的

所以say the experts和我同意。在.NET框架中还有其他约定，但是人们并不抱怨他们。

考虑到没有特殊原因也使用相似后缀的集合，字典，属性，列表和其他类型。他们会以任何方式工作，但是他们的用户更容易识别，他们的用户 – 本能地知道他们应该如何工作，何时使用它们。

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

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

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

原文地址：https://www.jb51.cc/aspnet/252998.html