CodeIgniter控制器之业务逻辑实例分析

本文实例分析了CodeIgniter控制器之业务逻辑。分享给大家供大家参考，具体如下：前面分析

本文实例分析了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');

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之类的，其实也可以按照上面的思路单独放在一个文件夹中处理，方便管理。