I generally have one controller for each logical group of functions. Often this will correspond with one controller per model, sometimes not.
Imagine you're creating a simple online catalog that displays a list of categories then when the user selects a category, displays a list of products from that category, along with an admin panel for CRUD operations on categories and products. I'd have two models (CategoryModel and ProductModel). I'd have a controller which generated the category listings for the front end, and another controller which generated the product listings (e.g. CategoryController and ProductController). I'd then have a controller for categories and products on the back end (AdminCategoryController and AdminProductController). The two back end controllers would handle list/add/edit/delete/view operations for their respective models. If you think though your URL structure and put related functions on related urls, then your controller structure will often match your URL structure. In fact some frameworks (e.g. CodeIgniter) route requests based on the name of the controller as default behavior.
As for what goes in the controllers, I work in the idea that Models are for data access, and wrap and hide the database structure. Logic such as "assign the current time to completion_date when status is set to 'complete'" is a great fit models.
Views contain the entirety of your presentation. Controllers/Models shouldn't generate or handle HTML. Decisions such as 2 columns or 3 belong in views. Logic in views should be restricted to that which is required to generate the visible output. If you find yourself wanting to query the database from a view, you're probably putting too much logic into the view.
Controllers are for what's left. Generally that means, validating input, assigning form data to models, selecting the right views and instantiating the models required to handle the request.
For the most part I follow the controller-per-model pattern. I have a few controllers that may serve multiple models (like the Admin controller which serves several administrative models), but the general rule is one controller per business model.
发布评论
评论（2）
我通常为每个逻辑功能组配备一个控制器。 通常，这与每个模型一个控制器相对应，有时则不然。
想象一下，您正在创建一个简单的在线目录，该目录显示类别列表，然后当用户选择一个类别时，显示该类别中的产品列表，以及用于对类别进行 CRUD 操作的管理面板和产品。 我有两个模型（
CategoryModel和ProductModel）。 我有一个为前端生成类别列表的控制器，以及另一个生成产品列表的控制器（例如CategoryController和ProductController）。 然后，我在后端有一个用于类别和产品的控制器（AdminCategoryController和AdminProductController）。 两个后端控制器将处理各自模型的列表/添加/编辑/删除/查看操作。 如果你仔细考虑你的 URL 结构并将相关函数放在相关的 url 上，那么你的控制器结构通常会与你的 URL 结构相匹配。 事实上，一些框架（例如 CodeIgniter）根据控制器名称路由请求作为默认行为。至于控制器中的内容，我的想法是模型用于数据访问，并包装和隐藏数据库结构。 诸如“当状态设置为‘完成’时将当前时间分配给completion_date”之类的逻辑非常适合模型。
视图包含整个演示文稿。 控制器/模型不应生成或处理 HTML。 诸如 2 列或 3 列之类的决策属于视图。 视图中的逻辑应限制为生成可见输出所需的逻辑。 如果您发现自己想要从视图查询数据库，则可能在视图中放入了太多逻辑。
控制器是为了剩下的东西。 一般来说，这意味着验证输入、将表单数据分配给模型、选择正确的视图并实例化处理请求所需的模型。
I generally have one controller for each logical group of functions. Often this will correspond with one controller per model, sometimes not.
Imagine you're creating a simple online catalog that displays a list of categories then when the user selects a category, displays a list of products from that category, along with an admin panel for
CRUDoperations on categories and products. I'd have two models (CategoryModelandProductModel). I'd have a controller which generated the category listings for the front end, and another controller which generated the product listings (e.g.CategoryControllerandProductController). I'd then have a controller for categories and products on the back end (AdminCategoryControllerandAdminProductController). The two back end controllers would handle list/add/edit/delete/view operations for their respective models. If you think though your URL structure and put related functions on related urls, then your controller structure will often match your URL structure. In fact some frameworks (e.g. CodeIgniter) route requests based on the name of the controller as default behavior.As for what goes in the controllers, I work in the idea that Models are for data access, and wrap and hide the database structure. Logic such as "assign the current time to completion_date when status is set to 'complete'" is a great fit models.
Views contain the entirety of your presentation. Controllers/Models shouldn't generate or handle HTML. Decisions such as 2 columns or 3 belong in views. Logic in views should be restricted to that which is required to generate the visible output. If you find yourself wanting to query the database from a view, you're probably putting too much logic into the view.
Controllers are for what's left. Generally that means, validating input, assigning form data to models, selecting the right views and instantiating the models required to handle the request.
在大多数情况下，我遵循每个模型一个控制器的模式。 我有一些可以服务于多个模型的控制器（例如服务于多个管理模型的管理控制器），但一般规则是每个业务模型一个控制器。
For the most part I follow the controller-per-model pattern. I have a few controllers that may serve multiple models (like the Admin controller which serves several administrative models), but the general rule is one controller per business model.