标签：codeigniter php
目前我正在做这样的事情：
控制器：立即调用模型,然后调用视图.除了确定要调用的模型和视图外,没有其他逻辑
模型：在我的数据库中包含每个表的所有功能.我的数据库中的每个表都有一个模型类及其方法.
视图：仅包含布局,几乎为零逻辑.
库：我所有不是特定于数据库表的类
第三方：已下载的插件
我的问题是,这正确吗？例如,是否应该始终将非表特定的类放在库中？如果我的类或函数是“产品”和“客户”表的组合,该怎么办？
提前致谢
解决方法:
根据角色(有时称为角色)来构造应用程序.换句话说,您不是基于“编辑”来构造控制器,而是基于“编辑器”以及他们需要做什么来构造控制器.这听起来像文字游戏,但实际上意义深远,因为“工具”应该为使用它们的人们服务.
例如,如果您有一个编辑器-然后为该编辑器创建“用例”-角色需要做什么以及他们正在操作哪些资产.然后,您的方法将来自这些用例.这也大大简化了安全性.您没有创建一个为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程序员)
这是对同一问题的一些有趣的回答
标签：codeigniter,php 来源： https://codeday.me/bug/20191122/2059813.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。