9

我有一个真正适用于任何 MVC 框架的问题,我正在使用 Zend Framework MVC。

你应该在什么时候创建一个新的控制器?控制器层究竟应该定义什么?

我用 MVC 创建了几个应用程序,逐渐变得更加可重用,但我一直在为控制器类命名而苦苦挣扎。在大多数情况下,它匹配任何 URL 请求,因此是业务/前端逻辑。但在某些情况下,这似乎完全是武断的。

有人可以遵循一些启发式/指南吗?似乎所有关于 MVC 的炒作,尤其是 PHP,关于实际约定和启发式的数据很少。因为创建一个杂乱无章的 MVC 应用程序非常容易......

4

2 回答 2

10

我通常为每个逻辑功能组配备一个控制器。通常这将对应于每个模型一个控制器,有时不是。

想象一下,您正在创建一个简单的在线目录,其中显示一个类别列表,然后当用户选择一个类别时,显示该类别的产品列表,以及一个用于CRUD对类别和产品进行操作的管理面板。我有两个模型(CategoryModelProductModel)。我有一个为前端生成类别列表的控制器,以及另一个生成产品列表的控制器(例如CategoryControllerProductController)。然后我会在后端有一个类别和产品的控制器(AdminCategoryControllerAdminProductController)。两个后端控制器将处理它们各自模型的列表/添加/编辑/删除/查看操作。如果您考虑您的 URL 结构并将相关函数放在相关 url 上,那么您的控制器结构通常会与您的 URL 结构匹配。事实上,一些框架(例如 CodeIgniter)基于控制器的名称作为默认行为路由请求。

至于控制器中的内容,我认为模型用于数据访问,并包装和隐藏数据库结构。诸如“当状态设置为‘完成’时将当前时间分配给完成日期”之类的逻辑非常适合模型。

视图包含整个演示文稿。控制器/模型不应生成或处理 HTML。2 列或 3 列等决策属于视图。视图中的逻辑应限于生成可见输出所需的逻辑。如果您发现自己想从视图中查询数据库,那么您可能在视图中放入了太多逻辑。

控制器用于剩下的东西。一般来说,这意味着验证输入、将表单数据分配给模型、选择正确的视图并实例化处理请求所需的模型。

于 2009-02-24T06:59:01.483 回答
1

在大多数情况下,我遵循每个模型的控制器模式。我有一些控制器可以服务于多个模型(例如服务于多个管理模型的 Admin 控制器),但一般规则是每个业务模型一个控制器。

于 2009-02-24T01:15:26.877 回答