在ASP.NET MVC中使用多个Controller类有什么好处？

我只是在学习ASP.NET MVC的基础知识,并且想知道在多个控制器之间分解网站逻辑的好处是什么,而不仅仅是拥有一个运行整个网站的Controller类,除了简单地组织代码.(在我看来,由于关注点分离,后者的好处不应该足以通过URL影响最终用户:站点的实现细节不应该反映在站点使用的URL中,不是吗？)

我一直在阅读的控制器上的一些示例显示了"Product"或"User"或"Post"等不同的控制器.这些明确对应于对象类,后面跟着可以采取的操作(现在看到url,我看到stackoverflow.com/questions/ask).

将网站拆分为单独的控制器类(例如QuestionsController)与仅具有单个默认控制器并在其中处理这些操作是否有优势,例如stackoverflow.com/ask-question(除了它看起来有点丑陋).

我问,因为我对我的网站RESTful并不特别感兴趣(我对它进行了一些调查,但认为它太有限)而是支持查询字符串参数来传递有关请求的信息.因此,将URL拆分为控制器和动作的概念对我来说没有意义,因为动作和类信息将在查询字符串中表示.

最后,我更喜欢简单的网址,比如www.mysite.com/about和www.mysite.com/home/about(这甚至意味着什么？),再次让我想知道多个控制器的真正意义点是什么.

您可以使用ASP.Net MVC路由实现几乎任何您想要的URL方案.您拥有哪些控制器以及您的操作位置与您的网址无关.只有路由定义了您的网址.因此,没有任何理由为了特定的url方案而牺牲代码清晰度和组织.

此外,在我看到的大多数ASP.Net MVC应用程序中,控制器已经很笨重,将它们全部组合到一个控制器中会以指数方式增加混乱.

即使是小型网站也有少数或两个控制器.重要网站有数十个,非常大的网站可能有数百个.你真的认为将几十个控制器组合成一个控制器是完全可行的吗？

ASP.NET MVC的美丽之处在于它使关注点分离变得如此简单。与ASP.NET Webforms的每个页面本质上都是视图和控制器不同，在ASP.NET MVC中，您可以将模型逻辑抽象为单独的关注点或“功能组”。拥有一个ProductsController来处理与Products有关的所有事情是很有意义的，因为这样您就可以将应用程序中的每组相关功能隔离到可以独立测试和维护的统一组中。

拥有DoEverythingController会从根本上击败MVC背后的推理，因为它将所有模型逻辑都聚集到一个巨大的意大利面条碗中，而不是保持整洁有序。此外，拥有可以执行所有操作的Controller并不是特别面向对象的，它类似于一种更具过程化的开发方法，就像许多（较旧的）PHP网站一样，这些网站具有一些可以执行所有操作的中央“ functions.php”或类似内容。这是混乱和混乱的。

关于最后一点，MVC中的路由引擎可让您构建到给定控制器操作的路由，但需要的话。只要您相应地定义路由，ControllerX的About（）操作和ControllerY的Contact（）操作都可以具有/ about和/ contact之类的根URL。

编辑（评论太长）

一般来说，就代码和逻辑而言，控制器类将非常薄。设计良好的控制器通常会执行更复杂的操作，例如将数据从数据存储中检索到某种服务，从而使故障的表面积保持很小。尽管大多数控制器都很“薄”，但您的站点越大，需要进行的操作就越多，通用控制器也将变得越来越笨重。即使在非MVC方案中，庞大的代码文件也需要维护和更新（例如，上面的“ functions.php”）。

如果您使用MVC开发的网站很小，并且仅限于几个静态页面，那么对所有页面使用单个控制器可能是一种合理的方法，但是如果您要构建一个可扩展的应用程序，随着时间的变化，放弃使用多个控制器将是真正的失败者。