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

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

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

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

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

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

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

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

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

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