Question

我最近开始使用CodeIgniter框架进行PHP开发。

我只是好奇才能正确使用。

基本上我有以下情况。

我有一个名为'items'的控制器

我希望如此，如果用户转到items / index，他们会得到一个caetgories列表，如果他们转到items / category-name，他们会得到一个项目列表。

为了实现这一点，我有一个带有if / elseif语句的控制器，它加载不同的视图。这是正确的方法吗？

如果我在某个商品/类别名称页面上，我会加载一个名为“items-list”的视图我将名为$ type的变量传递给此视图。

在视图中它检测到这种类型（再次使用if语句）并输出类别标题（也通过）。简单。

除此之外，我还有一个完全不同的控制器，用于最近出售的物品清单（不要问:)）。由于要显示的列表的格式基本相同，我使用相同的视图，但传递不同的$ type var。视图检测到这一点，输出各种“额外”链接，图像等，当然也不会输出“类别”标题。

基本上我有2个控制器使用一个视图。使用控制器和视图中的各种if / elseif语句来获得正确的输出。

这是正确的方法吗？

由于

Answer 1

简而言之......

没有单一的正确或错误的方法来构建您的控制器/视图/模型/库/帮助程序。

我也使用CI，我发现每个控制器方法中代码量最少的控制器最容易返回并编辑/维护/升级/读取。如果我的控制器方法中存在太多逻辑，则清晰度和理解会丢失。我尝试将大部分“逻辑”放在库或辅助方法中，因此我的控制器方法简单易读。

我喜欢让控制器接受参数/数据，将其发送到模型和/或库以及辅助方法，这些方法返回修改后的数据或新数据。在最终发送到视图之前，返回的数据可能会被发送到其他方法。

这种技术确实会在编写应用程序或网站时向您发送追逐多个文件，但实现了视图和逻辑的明确分离。希望它能帮助您编写可重复使用的代码，即使它只能在单个应用程序中重复使用。

无论对你和你的团队有什么作用，都没关系。

Answer 2

对于问题的第一部分，您应该查看CI的路由类：

http://codeigniter.com/user_guide/general/routing.html

这种方法没有任何根本性的错误，但你真的不需要两个控制器。大概是你这样做，以便你的URI在浏览器中正确显示？如果是这样，假设您目前拥有名为items和solditems的控制器。您可以设置这样的路线：

$ route ['solditems /（：any）'] =“items / solditems / $ 1”;

这样，当有人输入mysite.com/solditems/category时，脚本将在mysite.com/items/solditems/category的控制器上运行。

修改：我还应该添加一些关于模型的内容，因为它在你的标题中。从本质上讲，您希望控制器成为应用程序的“访问”层......基本上就是您现在拥有它的方式。显然，View包含您网站的视觉呈现。模型处理所有数据。如果你想得到所有产品的清单，你会想要一个“产品”模型和一个名为“getProducts”的东西。然后另一个称为“getProductById”或类似的东西。如果你很聪明，你会想出一个标准的数据格式化方法，这样你就可以随时了解数据调用的内容，从而可以直接将模型中的返回值传递给视图到你的控制器。因此，如果您想获得所有已售出的商品，您可以拥有一个处理请求的控制器并调用模型，模型将运行数据库查询并以您喜欢的任何方式将数据反馈回控制器，并且您的控制器将完全不知道返回的内容，但只是将该变量传递给视图以进行可视化处理。如果您有大量的视图，您也可以处理控制器中的一些演示逻辑（例如，如果您有一个视图是单个销售商品的“列表项”...您可以使用您的控制器迭代从模型返回的变量将它们一个接一个地传递给“list item”视图，连接该字符串（参见：$ this-＆gt; load-＆gt; view（）的可选第三个参数），然后粘贴该字符串进入“列表”视图。

只要您记住所有这一切的逻辑上是将访问层与表示层与数据层分开，您就可以获得所需的创意。除了那种抽象的分离，没有“最佳实践”，只有最适合你的。

Answer 3

像其他人所说的那样，并没有一种非常明确的“正确”方式。什么对你有用。对我来说，我通常每个动作使用一个视图。（如果该操作处理表单或其他内容，我会使用更多）。

例如我可能有：

'items/view/7'

具有特定产品的视图

'category/view/3'

，其中包含类别

的视图

当你更多地使用codeigniter时，你会发现你会发现更有条理的东西（因此对你来说更“可维护”）。对于一些小应用程序，我甚至在以后重新组织了所有内容（我的意思是字面意思，重新排列类和函数以及包含视图的文件夹），以使其更具逻辑性。

我没有看到任何与你正在做的事情“错误”的事情。虽然你的帖子的最后部分听起来的方式，你使用相同的视图，只是有变量来处理视图将要做的事情，我可能会避免这种情况（虽然它也取决于其他事情）。我可能只是对“最近售出的产品”有一个独立于“类别”视图的观点。让视图做很多逻辑并不是通常一个好主意。

MVC框架。什么时候需要新的视图/模型？

3 个答案:

简而言之......

无论对你和你的团队有什么作用，都没关系。