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

Question

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

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

我已经使用MVC创建了几个应用程序，逐渐变得更加可重用，但我总是在努力命名Controller类。在大多数情况下，它匹配任何URL请求，因此业务/前端逻辑。但在某些情况下，它似乎完全是武断的。

是否有人可以遵循一些启发式/指导方针？似乎所有关于MVC的炒作，尤其是PHP，关于实际约定和启发式的数据很少。因为创建一个混乱的MVC应用程序非常容易......

Answer 1

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

想象一下，您正在创建一个简单的在线目录，该目录显示一个类别列表，然后当用户选择一个类别时，显示该类别的产品列表，以及一个用于类别和CRUD操作的管理面板产品。我有两个模型（CategoryModel和ProductModel）。我有一个生成前端类别列表的控制器，以及生成产品列表的另一个控制器（例如CategoryController和ProductController）。然后，我会在后端（AdminCategoryController和AdminProductController）拥有类别和产品的控制器。两个后端控制器将处理各自模型的列表/添加/编辑/删除/查看操作。如果您考虑自己的URL结构并将相关功能放在相关网址上，那么您的控制器结构通常会与您的网址结构相匹配。实际上，一些框架（例如CodeIgniter）根据控制器的名称将请求路由为默认行为。

至于控制器中的内容，我的工作是模型用于数据访问，并包装和隐藏数据库结构。诸如“当状态设置为'完成'时将当前时间分配给completion_date”这样的逻辑是非常合适的模型。

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

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

Answer 2

在大多数情况下，我遵循每个模型的控制器模式。我有一些可以为多个模型服务的控制器（比如管理控制器，它提供多种管理模型），但一般规则是每个业务模型一个控制器。