CodeIgniter控制器之业务逻辑实例分析(控制器code是什么意思)

编辑：rootadmin

推荐整理分享CodeIgniter控制器之业务逻辑实例分析(控制器code是什么意思)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:codesys从控制器上载程序,控制器代码,codeigniter控制器跳转页面,codemeter控制中心怎么用,codemeter控制中心怎么用,codesys控制器,codeigniter控制器跳转页面,codesys控制器,内容如对您有帮助，希望把文章链接给更多的朋友！

本文实例分析了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方法，直接通过来调用。但业务逻辑很多都需要获取CI实例，这里可以参考模型的方法，core建立一个MY_Service,其他service均继承该类，这样子service里用法就跟控制器里一样了。

其实主要思路还是需要有一层用来处理业务逻辑，java中都有这一层。随着对CI的不断熟悉，发觉这里需要这一层，达到解放控制器和模型的目的。和这种类似的做法还有很多，如果系统中有很多地方需要用到web service 或者说cache之类的，其实也可以按照上面的思路单独放在一个文件夹中处理，方便管理。

更多关于CodeIgniter相关内容感兴趣的读者可查看本站专题：《codeigniter入门教程》和《CI(CodeIgniter)框架进阶教程》

希望本文所述对大家基于CodeIgniter框架的PHP程序设计有所帮助。

Twig模板引擎用法入门教程本文实例讲述了Twig模板引擎用法。分享给大家供大家参考，具体如下：介绍Twig是一个灵活、高效并且安全的PHP模板引擎。如果你使用过Smarty、Django或者

CodeIgniter配置之autoload.php自动加载用法分析本文实例分析了CodeIgniter配置之autoload.php自动加载用法。分享给大家供大家参考，具体如下：CodeIgniter带了自动加载的功能，可以全局加载类库、模型、

PHP连接MYSQL数据库实例代码现在做的项目需要php连接mysql数据库，虽然之前学过，但是现在基本上都给忘了，之后通过查找相关资料找到了解决方法，下面小编把具体方法分享在积