为什么这么多 MVC Web 框架喜欢将多个控制器操作分组到一个类中？
我的经验主要局限于 PHP，但据我所知，Rails 和 ASP.NET MVC 都走了同样的道路。
关键是，我遇到过的几乎每个 Web 框架都将控制器操作实现为方法，例如 create、edit、show 等。这些方法驻留在像 PostsController 这样的单个类中，但它们几乎从不共享状态或依赖项，因为在整个请求期间只调用其中一个方法。
这就是为什么对我来说这种方法似乎相当不合理，因为该类仅充当某种名称空间。看到由大块几乎不相关的控制器操作代码组成更大的控制器类的示例也没有帮助。然而，许多框架正是这样做的，只有少数框架为每个操作使用一个类。
那么问题来了，为什么会这样呢？也许这是主观的，但我相信我可能错过了这种方法的一个重要优点。
My experience is mostly limited to PHP, yet as far as I know both Rails and ASP.NET MVC have taken the same path.
The point is that nearly every web framework I've ever come across implements controller actions as methods, e.g. create, edit, show, etc. These methods reside in a single class like PostsController, but they hardly ever share state or dependencies, because only one of them gets called during the whole request.
That's why to me this approach seems quite unreasonable, as the class only acts as some kind of namespace. Seeing examples with large chunks of barely related controller action code composing even larger controller classes doesn't help either. Yet a lot of frameworks do exactly that, and only a few use a class for each action.
So the question is, why is it so? Perhaps it's subjective, but I believe that I may have missed an important advantage of this approach.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 MVC 设计模式一般规定了这种构建控制器的方法。控制器的主要目的是在关联视图和需要与之交互的模型之间提供适当的“连接”，以及处理来自视图的输入所需的任何业务逻辑。控制器应该只是这些其他组件之间的薄层。
例如，维基百科对控制器的描述如下：
我确实同意其他非 Web 环境中的控制器确实维护状态，但 PHP 中缺乏状态的原因很简单，因为 HTTP 是一种无状态协议。在这种环境中使用 MVC 本质上会导致控制器不维护状态。
I would argue that the MVC design pattern in general dictates this approach to building controllers. The main purpose of the controller is to provide the appropriate "wiring" between the associated view and the models it needs to interact with, along with any business logic needed to handle the input from the view. Controllers should just be a thin layer between these other components.
For example, Wikipedia describes the controller as follows:
I do agree that controllers in other, non-web environments do maintain state, but the reason for the lack of state in PHP, for example, is simply that HTTP is a stateless protocol. Using MVC in this environment is inherently going to result in controllers that don't maintain state.
这对于面向对象编程至关重要，从而形成适当分层的软件架构，其中控制器对象封装了有关域对象（模型）的所有职责。如果有 PostModel，那么应该有一个 PostController 负责调用域 api 上正确的业务方法来满足用户请求并将结果推送到视图中。在我看来，为每个可能的请求提供一个控制器类会导致程序化的结构化架构。
另一方面，如果控制器类中有太多职责，则应该将这些职责拆分为多个控制器。这取决于您手头的应用程序，没有一刀切的解决方案。每个控制器都应该负责域层上的一组有凝聚力的操作。
That is essential to object oriented programming resulting in a properly layered software architecture where the controller objects encapsulate all responsibilities about domain objects (model). If there is a PostModel, then there should be a PostController responsible for calling the right business methods on the domain api to satisfy the user request and to push the results into the view. Having a controller class for every single possible request leads to a procedural structured architecture in my opinion.
On the other hand, if you have too many resonsibilities in your controller class, you should split these responsibilities into multiple controllers. It depends on your application at hand, there is no one-fits-all solution. Every controller should be responsible for a cohesive group of actions on the domain layer.