《PHP教程:CodeIgniter控制器之业务逻辑实例分析》要点:
本文介绍了PHP教程:CodeIgniter控制器之业务逻辑实例分析,希望对您有用。如果有疑问,可以联系我们。
PHP学习本文实例分析了CodeIgniter控制器之业务逻辑.分享给大家供大家参考,具体如下:
PHP学习前面分析了公用控制器按模块分发,方便对特定模块的控制,而具体的实现类则是放在library中.那放在library中是否合适呢?以及控制器中更多的业务逻辑该放在哪里?
PHP学习先说下对CI中几个文件夹的理解
PHP学习helpers、libraries: 存放一系列辅助函数、辅助类,用来辅助控制器、业务逻辑实现功能.他们中的办法应当尽量避免与CI依赖,依赖越紧越难以复用.以邮件发送为例,发送邮件时很多参数是不变的,如编码、协议、端口等,我们可能会在config下进行配置这些参数,然后library封装一个邮件发送的类,并在其中获取CI实例后读取这些参数.此时就出现了与CI实例的依赖,该类就只能在CI框架中使用,其他系统要用到,就只能重写了,没达到复用的目的.如果发送的类只是接收参数,并封装发送办法呢?所以说,尽可能的让helpers、libraries变的简单,职责变得单一.
PHP学习controllers: 控制器目录.控制器主要用来接管程序,起到连接的作用.通常情况下,我们会把业务逻辑写在action中.但随着业务变得复杂,action代码将越来越臃肿,难以维护.
PHP学习models: 模型目录.CI的模型的主要职责就是和数据库打交道,获取数据.很多时候也会把业务逻辑放在模型中,但业务逻辑与模型实际上是两种东西了.模型只是获取数据,业务逻辑可能是把这些数据根据业务需要进行组合,组合方式可能有很多种,放在模型中会让模型难以维护且不利于复用.说个碰到的例子,对数据按一定条件做缓存,获取数据和缓存结果两个流程写在同一个办法中,但同样的数据需要做另一种形式的缓存时发现,获取数据的办法就没法重用了.
PHP学习third_party:第三方类库目录.拿到一个类库后不要直接使用, 可以在library中进行一次封装,让其更适应于系统,其他人使用起来难度也会降低.
PHP学习可以发现,每个文件夹都有自己的职责,每个模块都有自己的家,都有自己的职能.那业务逻辑该怎么办?
PHP学习既然这样, 我们也应该给业务逻辑安个家,建立一个唯一的目录用来存放业务逻辑,暂且命名为service.控制器主要负责接收参数并调用service,service来调用模型,各层各尽其责.
PHP学习下面看看怎么实现:
PHP学习我们可以重写MY_Load,增加service办法,直接通过
PHP学习
class MY_Service
{
public function __construct()
{
log_message('debug', "Service Class Initialized");
}
function __get($key)
{
$CI = & get_instance();
return $CI->$key;
}
}
PHP学习其实主要思路还是需要有一层用来处理业务逻辑,java中都有这一层.随着对CI的不断熟悉,发觉这里需要这一层,达到解放控制器和模型的目的.和这种类似的做法还有很多,如果系统中有很多地方需要用到web service 或者说cache之类的,其实也可以依照上面的思路单独放在一个文件夹中处理,方便管理.
PHP学习更多关于CodeIgniter相关内容感兴趣的读者可查看本站专题:《codeigniter入门教程》和《CI(CodeIgniter)框架进阶教程》
PHP学习希望本文所述对大家基于CodeIgniter框架的PHP程序设计有所赞助.
《PHP教程:CodeIgniter控制器之业务逻辑实例分析》是否对您有启发,欢迎查看更多与《PHP教程:CodeIgniter控制器之业务逻辑实例分析》相关教程,学精学透。维易PHP学院为您提供精彩教程。
转载请注明本页网址:
http://www.vephp.com/jiaocheng/7702.html