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方法，直接通过