MVC 框架。你什么时候需要新的视图/模型？
我最近开始使用 CodeIgniter 框架进行 PHP 开发。
我只是好奇正确的用法。
本质上我有以下情况。
我有一个名为“items”的控制器，
我想要它，所以如果用户转到 items/index 他们会得到一个类别列表，如果他们转到 items/category-name 他们会得到一个项目列表。
为了实现这一目标，我有一个带有 if/elseif 语句的控制器，可以加载不同的视图。这是正确的方法吗？
如果我在项目/类别名称页面上，我会加载一个名为“项目列表”的视图 我将一个名为 $type 的变量传递给该视图。
在视图中，它检测到此类型（再次使用 if 语句）并输出类别标题（也通过）。简单的。
除此之外，我还有一个完全不同的控制器用于最近出售的物品列表（不要问:)）。由于要显示的列表的格式本质上是相同的，因此我使用相同的视图，但传递不同的 $type var。该视图检测到这一点，输出各种“额外”链接、图像等，当然不会输出“类别”标题。
本质上我有 2 个控制器使用一个视图。在控制器和视图中使用各种 if/elseif 语句以获得正确的输出。
这是正确的方法吗？
谢谢
I have recently started using the CodeIgniter framework for my PHP development.
I was just curious as to correct usage.
Essentially I have the following situation.
I have a controller entitled 'items'
I want it so if the user goes to items/index they get a list of caetgories, if they go to items/category-name they get a list of items.
To achieve this, I have the one controller with an if/elseif statement which loads different views. Is this the correct approach?
If i am on a items/category-name page, I load a view entitled 'items-list'
I pass a variable entitled $type to this view.
In the view it detects this type (again with an if statement) and outputs the category title (also passed). Simple.
As well as this I have a completely different controller for a recently sold items list (dont ask :)). As the format of the list to display is essentially the same I utilize the same view, but pass a different $type var. The view detects this, outputs various 'extra' links, images etc and of course does not output a 'categories' title.
Essentially I have 2 controllers utilizing one view. With various if/elseif statements in both the controllers and the view to get the right output.
Is this the correct approach?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
简而言之......
构建控制器/视图/模型/库/助手的方法没有单一的正确或错误的方法。
我也使用 CI，并且我发现每个控制器方法中代码量最少的控制器是最容易返回并编辑/维护/升级/读取的。如果我的控制器方法中放置了太多逻辑，那么清晰度和理解就会丢失。我尝试将大部分“逻辑”放在库或辅助方法中，因此我的控制器方法简单且易于阅读。
我喜欢让控制器接受参数/数据，将其发送到模型和/或库和辅助方法，这些方法返回修改后的数据或新数据。返回的数据可能会在最终发送到视图之前发送到其他方法。
这种技术确实会让您在编写应用程序或网站时追逐多个文件，但可以实现视图和逻辑的清晰分离。希望它也能帮助您编写可重用的代码，即使它只能在单个应用程序中重用。
无论对您和您的团队有用，都可以。
In short...
there is no single right or wrong way to structure your controllers/views/models/libraries/helpers.
I too use CI, and I've found that controllers with the smallest amount of code in each controller method are the easiest to go back to and edit/maintain/upgrade/read. If too much logic is placed in my controller methods, clarity and understanding gets lost. I try to place most of my 'logic' in library or helper methods, so my controller methods are simple and easy to read.
I like to have the controller accept arguments/data, send it to models and/or library and helper methods, which return modified or new data. The returned data might get sent to other methods before finally being sent to a view.
This technique does tend to send you chasing around multiple files when writing an app or site, but achieves a clear separation of views and logic. Hopefully, it helps you write re-usable code too, even if it is only re-usable in the single app.
Whatever works for you and your team, is okay.
对于问题的第一部分，您应该查看 CI 的路由类：
http://codeigniter。 com/user_guide/general/routing.html
这种方法没有什么根本性的错误，但你确实不需要两个控制器。大概您这样做是为了让您的 URI 在浏览器中正确显示？如果是这样，假设您当前有名为 items 和 sellitems 的控制器。您可以设置这样的路线：
$route['solditems/(:any)'] = "items/solditems/$1";
这样，当有人输入 mysite.com/solditems/category 时，脚本将在 mysite.com/items/solditems/category 的控制器上运行。
编辑：我还应该添加一些关于模型的内容，因为它在你的标题中。本质上，您希望控制器成为应用程序的“访问”层……本质上与您现在所拥有的完全一样。显然，视图包含站点的视觉呈现。模型处理所有数据。如果您想获取所有产品的列表，您将需要一个“产品”模型和一个名为“getProducts”或其他名称的函数。然后另一个称为“getProductById”或类似的东西。如果您很聪明，您将想出一个标准的数据格式化方法，以便您始终知道数据调用会发生什么，从而可以通过 你的控制器。因此，如果您想获取所有已售出的商品，您可以有一个控制器来处理请求并调用模型，模型将运行数据库查询并以您喜欢的任何方式将数据吐回控制器，并且您的控制器将完全不知道返回的内容，而只是将该变量传递给视图以进行可视化处理。如果您有大量视图（例如，如果您有一个视图是单个已售商品的“列表项”），您还可以处理控制器中的一些表示逻辑...您可以使用控制器迭代从模型返回的变量，将它们一一传递到“列表项”视图，连接该字符串（请参阅：$this->load->view() 的可选第三个参数），然后粘贴 。
只要您记住这一切的目的是在逻辑上将访问层与表示层和数据层分开，您就可以发挥自己的创造力 没有“最佳实践”，只有最适合您的。
For the first part of your question, you should look at CI's routing class:
http://codeigniter.com/user_guide/general/routing.html
There's nothing fundamentally wrong with this approach, but you really don't need two controllers. Presumably you're doing this so that your URIs show up properly in the browser? If so, let's say you currently have controllers called items and solditems. You could set up a route like this:
$route['solditems/(:any)'] = "items/solditems/$1";
That way, when someone types in mysite.com/solditems/category the script will run at the controller at mysite.com/items/solditems/category.
Edit: I should also add something about models since it was in your title. In essence, you want to have controllers be the "access" layer for your applications...essentially exactly how you have it now. View, obviously, contain the visual presentation of your site. Models handle all things data. If you want to get a list of all products, you will want a "products" model and a function in there called "getProducts" or something. Then another called "getProductById" or something like that. If you're smart, you'll come up with a standard data formatting method so that you always know what to expect from your data calls, and thus can pass return values directly from your model to your view through your controller. So if you want to get all sold items, you can have a controller that does handles the request and makes the call to the model, the model will run the database query and spit the data back to the controller in any manner you like, and your controller will be entirely agnostic as to what comes back, but simply passes that variable to the view to be processed visually. You could also handle some of the presentation logic in your controller if you have a large number of views (e.g. if you have one view that is a "list item" for a single one of your sold items...you can use your controller to iterate through the variable returned from the model passing them one by one to the "list item" view, concatenating that string (see: the optional third parameter for $this->load->view()), and then pasting that string into a "list" view.
You can get as creative as you want as long as you remember that the point of all this is to logically separate the access layer from the presentation layer from the data layer. Beyond that abstract separation, there are no "best practices", just what's best for you.
正如其他人所说，没有一个真正明确的“正确”方法。无论什么对你有用。对我来说，我通常每个操作使用一个视图。 （如果该操作处理表单或其他内容，我会使用更多）。
例如，我可能有：
其中有一个特定产品的视图
有一个类别的视图
您会发现，当您更多地使用 codeigniter 时，您会发现东西更有条理（因此对您来说更“可维护”） 。对于一些小型应用程序，我什至后来重新组织了所有内容（我的意思是字面意思，重新排列了包含视图的类、函数和文件夹），只是为了使其更符合逻辑。
我不认为你所做的事情有什么“错误”。虽然听起来你的帖子的最后部分是这样的，你使用相同的视图，并且只有变量来处理视图将要执行的操作，但我可能会避免这种情况（尽管它也取决于其他事情）。我可能只会有一个独立于“类别”视图的“最近销售的产品”视图。让视图执行大量逻辑通常并不是一个好主意。
Like others have stated, there's not a really clear-cut "right" way. Whatever works for you. For me, I generally use about one view per action. (I use more if that action handles a form or something).
For example I might have:
which has a view for a specific product
which has a view for a category
You'll find as you use codeigniter more, you'll find things that are more organized (and therefore more "maintainable" to you). And with some small applications, I've even reorganized everything later on (I mean literally, rearranged classes and functions and folders containing views) just to make it more logical.
I don't see anything that's "wrong" with what you're doing. Though the way it sounds with the last part of your post, where you use the same view and just have variables that process what the view is going to do, I would probably avoid this (though it depends on other things too). I would probably just have a view for "recent sold products" that was independent of the "category" view. Having the view do very much logic isn't usually a good idea.