Codeigniter PHP 中的 MVC 设计
什么时候应该制作新模型或控制器？是否应该只存在与相应的视图 1 对 1 配合的控制器，就像控制器和模型一样？或者让功能控制器不与任何特定视图绑定是一个好习惯吗？以投票为例，所有投票代码应该放入投票控制器中，还是分散在有投票意见的控制器中。似乎投票控制器可能是最好的。
When should a new model or controller be made? Should there only be controllers that go with a corresponding view 1 to 1 and like so with controllers and models? Or is it good practice to have controllers for functionality not tied up with any particular view? Take for example voting, should all voting code go in a voting controller or be spread among controllers that have views using voting. Seems likely a voting controller would be best.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
首先，你实际上无法在 php 中实现经典的 MVC。你能做的最好的事情就是 Model2 MVC。
您可以在视图与控制器或
多:多之间建立1:1关系。这取决于您如何实现视图本身。例如，您的视图可能需要一个单独的对象来处理渲染。并提供不同类型的对象（这就是多态性的重要性），您可以使视图呈现 xml、html 或 json。
或者您可以通过更改模板来执行相同的操作。如果基本表示逻辑不改变并且您只为每个内容提供不同的模板，则
ListView类可以呈现文章列表和用户列表。在投票的情况下，使用一个控制器来处理所有投票相关的操作似乎是可以的，并且您可以通过切换输出模板来获得单个视图。
First of all , you cannot actually implement classical MVC in php. The best you can do is Model2 MVC.
You can wither have
1:1relationship between views an controller ormany:many. it depends on how you implement the view itself.For example, your view can require a separate object which handles the rendering. And providing different type of objects ( this is where polymorphism matters ), you can make your view to render either xml, html or json.
Or you can do the same by changing the templates. A
ListViewclass can render a list of articles as well as list of users, if the basic presentation logic does not change and you provide just a different template for each.In the case of voting , it seems ok to have a single controller for all voting related operations, and you can have a single view with switching the templates for your output.
这类事情有些取决于偏好和观点；有些则取决于偏好和观点。没有唯一正确的方法。有些方法可能更灵活，但可能会变得更复杂。
关于您的“投票”示例，这可能取决于您的网站将如何使用投票。投票会出现在不同类型的页面上吗？如果是这样，某种组件是一个好方法；然后，投票组件视图可用于在不同页面中显示其数据，投票组件控制器接受投票结果，然后可能重定向到其他地方（或通过 Ajax 请求接受投票）。
通常，您会发现模型（和控制器）或多或少以 1:1 的方式映射到数据库中的表。因此，如果我有一个表
users，我可能有一个相应的User模型和UserController控制器。请记住控制器的用途：响应请求，确定需要加载哪些模型，然后要求它们存储、操作和返回数据，然后将数据传输到视图进行显示。拥有不直接映射到模型的控制器很好。您可能有一个名为
DebugController的控制器，它响应对http://examples.com/debug/的请求，并且不直接映射到Debug< /code> 模型和表，但收集有关系统和各种模型的信息（当然，有人认为所有这些东西应该包装到调试模型中，进而加载其他模型并组装控制器的数据要求）。至于视图，对于给定的控制器，通常会有多个视图；通常每个操作一次查看。所以
UserController::indexAction()有views/user/index.php，UserController::editAction()有views/user /edit.php等Some of this sort of thing is down to preferences and opinion; there's no single correct way. Some approaches might be more flexible, but maybe at the expense of being more complex.
With regard to your example of "voting", that may depend upon how voting is going to be used in your site. Will votes appear on different types of pages? If so, some sort of component is a good approach; the voting component view can then be used to display its data within different pages, with a Voting component controller accepting the results of votes and then maybe redirecting somewhere else (or accepting votes by an Ajax request).
Very often you'll find that a models (and controllers) map more or less 1:1 to tables in a database. So if I have a table
users, I might have a correspondingUsermodel, andUserControllercontroller.Remember what a controller is intended to do: respond to a request, working out which models need to be loaded, then asking them to store, manipulate and return data which is then transferred to the view for displaying. It's fine to have controllers that don't map directly to models. You might have a controller called
DebugControllerthat responds to requests tohttp://examples.com/debug/, and doesn't map directly to aDebugmodel and table, but gathers information about the system and various models (of course, there is the argument that all that stuff should be wrapped up into aDebugmodel, which in turn loads other models and assembles the data that the controller requests).As for views, you will normally have more than one view for a given controller; often one view per action. So
UserController::indexAction()hasviews/user/index.php,UserController::editAction()hasviews/user/edit.phpetc.这种方法可能是灵活的，这是事实。
模型 - 描述直接与数据库通信的层以及所有 SQL 查询。
您可以为数据库中的每个表建立模型，该模型将处理连接到该表的所有操作（选择、插入、更新、删除）。
您可以为每个“逻辑实体”建立模型，应用程序中的模块将处理该实体的操作。就像您的示例“投票”一样，您可以在其中定义该模块的逻辑。
（检查用户是否已投票，getVoteCount...）
Controler - 通过执行模型中的函数（它们不应直接在数据库中通信）并将处理后的数据传递给适当的视图来处理请求。如果您需要在不同页面上以不同方式呈现相同的数据，则控制器应决定发送数据的视图。
视图 - 您需要查看应用程序中的每个页面、表单、模块。如何组织观点取决于个人经验。
The approach might be flexible, that is true.
Models - Describe the tier that is communicating directly with database, all the SQL queries.
You can have model for each table in DB that will handle all actions connected to that table (select, insert, update, delete).
You can have model for each "logical entity", modul in your application that will handle the actions for this entity. Like in your example "Voting", where you can define the logic of this modul.
(Check if the user has allready voted, getVoteCount...)
Controler - Handle the request by executing functions in the model (they should not comunicate directly in DB) and passing the processed data to appropriate View. If you need to present the same data differently on different page, the controler should decide on which view to send the data.
View - You need view for each page, form, module in you application. It is on personal experiance how you are going to organize the views.