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