CI, CI
CI stand for CodeIgniter, 代码加速器，一个轻便的PHP框架. lightweigh对于PHP是很重要的, 对于每一个請求,PHP都是重新初始化所有的资源,包括内存,数据库,文件源. 请求结束后, 又将所有的资源销毁掉, 因此这PHP比较不会出现memery leak之类的错误,就算代码写得很烂.
在框架大行其道的时候,PHP也玩上了框架,越玩越大, PHP本身也越搞越复杂. 而框架的初始是需要很多资源的,特别是一些比较大的框架, 而很多时候的请求并不需要初始化太多东西, 因此PHP的开发越来越快, 运行速度,性能就越来越慢.
基于PHP这种特性,且也不太喜欢他的语法, 因此大学结束后基本没接触过PHP. 后来因为项目关系, 重新拾起了PHP. 项目使用了CI框架, 所以也就对此进行了研究.
CI 也玩MVC, 所有的请求都是通过前端index.php这个控制器, 根据URI转发给相应的控制器完成业务逻辑, 数据结果传给View, 前端控制器调用View的结果(Output)返回给web服务器. 整个过程比较清晰.
CI 关键类是Config, Router, URI, Output
a. Config主要是加载系统的配置信息
b. URI通过分析请求URL(PATH_INFO,REQUEST_URI...),获取请求信息,也叫request_string,比如请求/index.php/product/list/1/2, 分析结果是/product/list/1/2
c. Router通过URI的request_string,得到相应的类和方法.CI 的URI是restful的,约定大于配置.比如请求/index.php/product/list/1/2, 表示请求Product类的list方法, 1,2是传给方法的参数(位置相关)
d. 主控制器通过Router得到类和方法, 调用,生成相应的结果Output. 主控制器返回结果给web服务器
CI 会初始化几个关键的类, 之后需要用到的各种libraries, helper是通过Loader这个关键类进行动态加载的.包括database相关的类, 各种应用相关的帮助类
CI 的database
采用了Active Record这个模式, 可以向database发送平台有关的sql命令, 也可忽略database平台,而采用Active Record. 一开始我是不想用ActiveRecord的,因为他把sql的各部分根据后台数据库平台组装成平台相关的sql, 我是怕这里可能比较耗资源, 也喜欢直接写长长的sql, 但是后来想想可能要支持多个数据库,比如mysql, pgsql, oracle. 还是使用Active Record.数据库是相对比较耗资源的操作,数据能缓存就尽量缓存,能不初始化数据库连接就不去初始化
CI的错误控制Exception
首先他将php的错误通过set_error_handler由自己控制, 通过Exception, Log将错误重新包装,写入相关日志.对其他各种错误也是通过Exception,Log进行处理.
CI的核心点Controller
Controller有各种关键类的引用, 特别是loader, 可以在方法中加载需要的类. $this->load->module,$this->load->helper, $this->load->libraries, $this->load->database, $this->load->view
尽量只在需要的方法中load, 特别是database.
CI的数据模式Module类
Module一般表示关系数据库中的一个表, 相关的数据库操作都可以在此操作, 结果由Controller来获取.Module初始化的时候会将Controller的关键类引用也导入自己的引用,因此他也有loader之类的对象属性
CI的展示层View类
CI不推荐使用模板引擎, 他本身也有个简单的模板引擎.我也觉得在html中使用原生PHP好过新的模板语言, 一来是模板语言最終还是要转化为PHP,这有个性能问题, 二来嵌入html本就是PHP以前干的事,对前端也不会有太大的困扰,也不会有复杂的逻辑,更不会有业务相关逻辑.
View是通过Controller调用的,因此View里面可以使用$this->load->view()进行页面嵌套, 而Controller其他属性对象如$this->db之类的就不推荐使用了.
Controller将view的结果传到Output类中, 前端控制器调用Output相关方法取出结果返回web服务器
CI的一些问题:
经过研究CI的源码, 发现一些不知是不是问题的问题
a. Loader加载library时,会重新对已加载的Module进行_assign_libraries,也就是为了将这个library的引用加入到Module,我觉得是多余的.因为一个library对Module不会有很大的作用,就算有,也可以在Module中自己加载, 况且Module初始化时会自己_assign_libraries.因为library一般是先于Module进行加载的.
Loader加载Module还有个_assign_libraries的重复操作
b. DB_driver中query方法,如果请求失败, 如果没有设置debug为true的话,是没有任何提示的, 我觉得应该在这个点上提供一个口,可以进行Log之类的操作.
还有就是DB_utility,DB_forge简直是鸡肋, 这两个类基本是一些数据库修改的操作,比如create_database, list_databases,这些方法对于想写phpAdmin之类的应用可能比较有用, 对一般的应用就是鸡肋.而偏偏这些鸡肋在数据库加载时也加载了,简直是浪费资源
c. Router的 _parse_request_uri方法没有效果,写得乱七八糟,最简单的就是将index.php跟之前的内容去掉,后面的内容就是所需的request_string
d. 还有scaffolding也是鸡肋,CI也不推荐使用了,不安全.
f. 在linux下,文件名是区分大小写的,因此load controller,module时可能会出现找不到文件的错误,而在window下没有此问题.
所以controler的类名应该跟url中的类字段大小写一样才行
至于module 可以在Loader.php中的module方法下注释掉
$module = strtolower($module)
g.还有就是在linux下database.php配置文件的hostname如果是localhost的话会出现连接不了，可以换成127.0.0.1
在框架大行其道的时候,PHP也玩上了框架,越玩越大, PHP本身也越搞越复杂. 而框架的初始是需要很多资源的,特别是一些比较大的框架, 而很多时候的请求并不需要初始化太多东西, 因此PHP的开发越来越快, 运行速度,性能就越来越慢.
基于PHP这种特性,且也不太喜欢他的语法, 因此大学结束后基本没接触过PHP. 后来因为项目关系, 重新拾起了PHP. 项目使用了CI框架, 所以也就对此进行了研究.
CI 也玩MVC, 所有的请求都是通过前端index.php这个控制器, 根据URI转发给相应的控制器完成业务逻辑, 数据结果传给View, 前端控制器调用View的结果(Output)返回给web服务器. 整个过程比较清晰.
CI 关键类是Config, Router, URI, Output
a. Config主要是加载系统的配置信息
b. URI通过分析请求URL(PATH_INFO,REQUEST_URI...),获取请求信息,也叫request_string,比如请求/index.php/product/list/1/2, 分析结果是/product/list/1/2
c. Router通过URI的request_string,得到相应的类和方法.CI 的URI是restful的,约定大于配置.比如请求/index.php/product/list/1/2, 表示请求Product类的list方法, 1,2是传给方法的参数(位置相关)
d. 主控制器通过Router得到类和方法, 调用,生成相应的结果Output. 主控制器返回结果给web服务器
CI 会初始化几个关键的类, 之后需要用到的各种libraries, helper是通过Loader这个关键类进行动态加载的.包括database相关的类, 各种应用相关的帮助类
CI 的database
采用了Active Record这个模式, 可以向database发送平台有关的sql命令, 也可忽略database平台,而采用Active Record. 一开始我是不想用ActiveRecord的,因为他把sql的各部分根据后台数据库平台组装成平台相关的sql, 我是怕这里可能比较耗资源, 也喜欢直接写长长的sql, 但是后来想想可能要支持多个数据库,比如mysql, pgsql, oracle. 还是使用Active Record.数据库是相对比较耗资源的操作,数据能缓存就尽量缓存,能不初始化数据库连接就不去初始化
CI的错误控制Exception
首先他将php的错误通过set_error_handler由自己控制, 通过Exception, Log将错误重新包装,写入相关日志.对其他各种错误也是通过Exception,Log进行处理.
CI的核心点Controller
Controller有各种关键类的引用, 特别是loader, 可以在方法中加载需要的类. $this->load->module,$this->load->helper, $this->load->libraries, $this->load->database, $this->load->view
尽量只在需要的方法中load, 特别是database.
CI的数据模式Module类
Module一般表示关系数据库中的一个表, 相关的数据库操作都可以在此操作, 结果由Controller来获取.Module初始化的时候会将Controller的关键类引用也导入自己的引用,因此他也有loader之类的对象属性
CI的展示层View类
CI不推荐使用模板引擎, 他本身也有个简单的模板引擎.我也觉得在html中使用原生PHP好过新的模板语言, 一来是模板语言最終还是要转化为PHP,这有个性能问题, 二来嵌入html本就是PHP以前干的事,对前端也不会有太大的困扰,也不会有复杂的逻辑,更不会有业务相关逻辑.
View是通过Controller调用的,因此View里面可以使用$this->load->view()进行页面嵌套, 而Controller其他属性对象如$this->db之类的就不推荐使用了.
Controller将view的结果传到Output类中, 前端控制器调用Output相关方法取出结果返回web服务器
CI的一些问题:
经过研究CI的源码, 发现一些不知是不是问题的问题
a. Loader加载library时,会重新对已加载的Module进行_assign_libraries,也就是为了将这个library的引用加入到Module,我觉得是多余的.因为一个library对Module不会有很大的作用,就算有,也可以在Module中自己加载, 况且Module初始化时会自己_assign_libraries.因为library一般是先于Module进行加载的.
Loader加载Module还有个_assign_libraries的重复操作
b. DB_driver中query方法,如果请求失败, 如果没有设置debug为true的话,是没有任何提示的, 我觉得应该在这个点上提供一个口,可以进行Log之类的操作.
还有就是DB_utility,DB_forge简直是鸡肋, 这两个类基本是一些数据库修改的操作,比如create_database, list_databases,这些方法对于想写phpAdmin之类的应用可能比较有用, 对一般的应用就是鸡肋.而偏偏这些鸡肋在数据库加载时也加载了,简直是浪费资源
c. Router的 _parse_request_uri方法没有效果,写得乱七八糟,最简单的就是将index.php跟之前的内容去掉,后面的内容就是所需的request_string
d. 还有scaffolding也是鸡肋,CI也不推荐使用了,不安全.
f. 在linux下,文件名是区分大小写的,因此load controller,module时可能会出现找不到文件的错误,而在window下没有此问题.
所以controler的类名应该跟url中的类字段大小写一样才行
至于module 可以在Loader.php中的module方法下注释掉
$module = strtolower($module)
g.还有就是在linux下database.php配置文件的hostname如果是localhost的话会出现连接不了，可以换成127.0.0.1