目前我正在做这样的事情：
控制器：立即调用模型,然后调用视图.除了确定要调用的模型和视图外,没有其他逻辑
模型：在我的数据库中包含每个表的所有功能.我的数据库中的每个表都有一个模型类及其方法.
视图：仅包含布局,几乎为零逻辑.
库：我所有不是特定于数据库表的类
第三方：已下载的插件
我的问题是,这正确吗？例如,是否应该始终将非表特定的类放在库中？如果我的类或函数是“产品”和“客户”表的组合,该怎么办？
提前致谢
解决方法:
根据角色(有时称为角色)来构造应用程序.换句话说,您不是基于“编辑”来构造控制器,而是基于“编辑器”以及他们需要做什么来构造控制器.这听起来像文字游戏,但实际上意义深远,因为“工具”应该为使用它们的人们服务.
例如,如果您有一个编辑器-然后为该编辑器创建“用例”-角色需要做什么以及他们正在操作哪些资产.然后,您的方法将来自这些用例.这也大大简化了安全性.您没有创建一个为5个不同用户提供5个不同安全配置的控制器.您只需拥有具有其独特安全性的编辑器-一旦您建立了他们的证书(登录),就无需反复检查它.
命名至关重要.这是易于理解的应用程序与令人困惑的应用程序之间的主要区别.允许您自己更改和完善您的控制器,模型,方法名称,以使它们变得更加清晰.您应该能够查看您的models文件夹,查看模型的名称-并确切地知道应用程序的功能.
一种方法应该做一件事并且做得很好.如果您的方法执行3种不同的操作,请将其分为3种方法.
在模型变大时将其拆分,然后与文件夹一起排列.哪一种会更容易-在1000行代码或300行代码中找到一种方法？拆分模型可以使其速度更快,因为这样您还可以在模型命名方面更加具体.如果模型很复杂,那么只做一件事情就很好.
个人而言,如果您使用的是CI,我建议您专注于构建模型而不是库.另一个建议是内置控制器-然后在完成代码时将代码推送到模型中.就像联系表格一样-您可以在控制器中建立验证,以便将所有代码放在一起并易于使用.完成它,然后将验证代码推入其自己的模型.
(您提到的产品/客户-Codeigniter非常适合电子商务)
=====
编辑
命名-(摇头)是的,我还在学习.我会说一件事-我不认为在您的模型名称中加上“模型”一词是一种好习惯
$this->user_model->getUser($id) ;
有一阵子我以为这种模式真的很
$this->user_m->getUser($id) ;
我写了一篇关于它有多酷的文章.然后我意识到这根本不酷,并删除了帖子！考虑一下-您不会从控制器中调用其他控制器.您只调用模型.那么为什么到处重复“模型”一词呢？
$this->user->getUser($id) ;
所以多数民众赞成在我可能会开始.但是现在我们想尝试使其可读性如何
$this->user->getBy($id) ;
“此用户通过ID获取”-很清楚发生了什么.您可以大声读出来,而且很有意义.这是关键测试.这也意味着新手可以查看您的代码并更快地理解它.
马丁在大声朗读代码方面大有作为-一开始听起来很愚蠢,但这对代码的长期可维护性具有重大影响.
我来回回想的一件事-应该是“获取”还是“返回”-我通常使用get,因为它简短而直接.
如果您不确定是否会有该ID的用户,我将使用Find.如果您得到一堆东西-例如搜索产品-可能没有任何结果,则可能是searchFor($item)或类似的东西.
再一次,我会看你所有的罗伯特·马丁视频.并继续尝试不同的命名约定.大声说出来.另一个角度是,您将不得不写更少的评论.
好的,这是另一条准则-写下您的变量名,使它们有意义.不要缩写它们.
$first // NO why? first what??
$firstname or $first_name or $firstName // yes first name
这是Robert C Martin的一些命名规则
小范围的方法应具有长而精确的名称.长范围的方法应具有通用名称.
您不必阅读方法的主体即可知道它的作用.它的名字应该告诉你.
方法的行为越复杂,其名称就越通用,并且应该从中提取更多的子方法.
请注意-在他的演讲等中,我从未听过罗伯特·马丁说过字母php.他可能不认为这是一种真正的语言.但令人敬畏的是,他的示例主要是用Java编写的,其语法与用codeigniter编写方法非常相似. (因此,不必担心您不是Java程序员)
这是对同一问题的一些有趣的回答