你应该在MVC中命名你的控制器？你应该什么时候创建一个新的？

Question

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

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

我用MVC创建了几个应用程序，逐渐变得更加可重用，但我一直在努力控制命名Controller类。大多数情况下，它匹配任何URL请求，所以业务/前端逻辑。但在某些情况下，这似乎完全是任意的。

有没有人有一些启发式/指引要遵循？似乎所有关于MVC的炒作，特别是在PHP中，关于实际约定和启发式的数据很少。因为创建混乱的MVC应用程序非常容易...

Answer 1

我对于每个逻辑功能组一般都有一个控制器。通常这将与每个型号的一个控制器相对应，有时不会。

想象一下，您正在创建一个简单的在线目录，显示一个类别列表，然后当用户选择一个类别时，显示该类别的产品列表，以及用于CRUD操作类别和产品的管理面板。我有两个型号（CategoryModel和ProductModel）。我会有一个控制器为前端生成类别列表，另一个控制器生成产品列表（例如CategoryController和ProductController）。然后，我会在后端有一个控制器，用于类别和产品（AdminCategoryController和AdminProductController）。两个后端控制器将处理各自型号的列表/添加/编辑/删除/查看操作。如果您认为您的网址结构并将相关功能放在相关的网址上，那么您的控制器结构通常会与您的网址结构相匹配。实际上，一些框架（例如CodeIgniter）根据控制器的名称路由请求作为默认行为。至于在控制器中发生了什么，我工作的观点是模型用于数据访问，并包装和隐藏数据库结构。诸如“当状态设置为”完成“时将当前时间分配给completion_date的逻辑”是非常适合的模型。

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

控制器是为了剩下的。通常这意味着验证输入，将表单数据分配给模型，选择正确的视图并实例化处理请求所需的模型。

Answer 2

对于大多数情况，我遵循控制器每模型模式。我有几个控制器可以为多个模型提供服务（如管理员控制器可以为多个管理模型提供服务），但一般规则是每个业务模型都有一个控制器。