我有一个真正适用于任何 MVC 框架的问题，我正在使用 Zend Framework MVC。
你应该在什么时候创建一个新的控制器？控制器层究竟应该定义什么？
我已经使用 MVC 创建了多个应用程序，这些应用程序逐渐变得更加可重用，但我一直在为控制器类命名而苦恼。在大多数情况下，它匹配任何 URL 请求，因此是业务/前端逻辑。但在某些情况下，这似乎完全是武断的。
有人可以遵循一些启发式/指南吗？似乎所有关于 MVC 的炒作，尤其是 PHP，关于实际约定和启发式的数据很少。因为创建一个杂乱无章的 MVC 应用程序非常容易......
【问题讨论】：
标签： model-view-controller controller heuristics
我通常为每个逻辑功能组配备一个控制器。通常这将对应于每个模型一个控制器，有时不是。
假设您正在创建一个显示类别列表的简单在线目录，然后当用户选择一个类别时，会显示该类别的产品列表，以及一个用于对类别和产品进行CRUD 操作的管理面板。我有两个模型（CategoryModel 和 ProductModel）。我有一个为前端生成类别列表的控制器，以及另一个生成产品列表的控制器（例如CategoryController 和ProductController）。然后我会在后端有一个类别和产品的控制器（AdminCategoryController 和AdminProductController）。两个后端控制器将处理它们各自模型的列表/添加/编辑/删除/查看操作。如果您考虑您的 URL 结构并将相关函数放在相关 url 上，那么您的控制器结构通常会匹配您的 URL 结构。事实上，一些框架（例如 CodeIgniter）根据控制器的名称作为默认行为路由请求。
至于控制器中的内容，我认为模型用于数据访问，并包装和隐藏数据库结构。诸如“当状态设置为‘完成’时将当前时间分配给完成日期”之类的逻辑非常适合模型。
视图包含整个演示文稿。控制器/模型不应生成或处理 HTML。 2 列或 3 列等决策属于视图。视图中的逻辑应限于生成可见输出所需的逻辑。如果您发现自己想从视图中查询数据库，那么您可能在视图中放入了太多逻辑。
控制器用于剩下的东西。一般来说，这意味着验证输入、将表单数据分配给模型、选择正确的视图并实例化处理请求所需的模型。
【讨论】：
在大多数情况下，我遵循每个模型的控制器模式。我有一些控制器可以服务于多个模型（例如 Admin 控制器，它服务于多个管理模型），但一般规则是每个业务模型一个控制器。
【讨论】：