[size=medium]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服务器. 整个过程比较清晰.
[b]CI 关键类是Config, Router, URI, Output[/b]
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相关的类, 各种应用相关的帮助类
[b]CI 的database[/b]
采用了Active Record这个模式, 可以向database发送平台有关的sql命令, 也可忽略database平台,而采用Active Record. 一开始我是不想用ActiveRecord的,因为他把sql的各部分根据后台数据库平台组装成平台相关的sql, 我是怕这里可能比较耗资源, 也喜欢直接写长长的sql, 但是后来想想可能要支持多个数据库,比如mysql, pgsql, oracle. 还是使用Active Record.数据库是相对比较耗资源的操作,数据能缓存就尽量缓存,能不初始化数据库连接就不去初始化
[b]CI的错误控制Exception[/b]
首先他将php的错误通过set_error_handler由自己控制, 通过Exception, Log将错误重新包装,写入相关日志.对其他各种错误也是通过Exception,Log进行处理.
[b]CI的核心点Controller[/b]
Controller有各种关键类的引用, 特别是loader, 可以在方法中加载需要的类. $this->load->module,$this->load->helper, $this->load->libraries, $this->load->database, $this->load->view
尽量只在需要的方法中load, 特别是database.
[b]
CI的数据模式Module类[/b]
Module一般表示关系数据库中的一个表, 相关的数据库操作都可以在此操作, 结果由Controller来获取.Module初始化的时候会将Controller的关键类引用也导入自己的引用,因此他也有loader之类的对象属性
[b]CI的展示层View类[/b]
CI不推荐使用模板引擎, 他本身也有个简单的模板引擎.我也觉得在html中使用原生PHP好过新的模板语言, 一来是模板语言最終还是要转化为PHP,这有个性能问题, 二来嵌入html本就是PHP以前干的事,对前端也不会有太大的困扰,也不会有复杂的逻辑,更不会有业务相关逻辑.
View是通过Controller调用的,因此View里面可以使用$this->load->view()进行页面嵌套, 而Controller其他属性对象如$this->db之类的就不推荐使用了.
Controller将view的结果传到Output类中, 前端控制器调用Output相关方法取出结果返回web服务器
[b]CI的一些问题:[/b]
经过研究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
[/size]
在框架大行其道的时候,PHP也玩上了框架,越玩越大, PHP本身也越搞越复杂. 而框架的初始是需要很多资源的,特别是一些比较大的框架, 而很多时候的请求并不需要初始化太多东西, 因此PHP的开发越来越快, 运行速度,性能就越来越慢.
基于PHP这种特性,且也不太喜欢他的语法, 因此大学结束后基本没接触过PHP. 后来因为项目关系, 重新拾起了PHP. 项目使用了CI框架, 所以也就对此进行了研究.
CI 也玩MVC, 所有的请求都是通过前端index.php这个控制器, 根据URI转发给相应的控制器完成业务逻辑, 数据结果传给View, 前端控制器调用View的结果(Output)返回给web服务器. 整个过程比较清晰.
[b]CI 关键类是Config, Router, URI, Output[/b]
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相关的类, 各种应用相关的帮助类
[b]CI 的database[/b]
采用了Active Record这个模式, 可以向database发送平台有关的sql命令, 也可忽略database平台,而采用Active Record. 一开始我是不想用ActiveRecord的,因为他把sql的各部分根据后台数据库平台组装成平台相关的sql, 我是怕这里可能比较耗资源, 也喜欢直接写长长的sql, 但是后来想想可能要支持多个数据库,比如mysql, pgsql, oracle. 还是使用Active Record.数据库是相对比较耗资源的操作,数据能缓存就尽量缓存,能不初始化数据库连接就不去初始化
[b]CI的错误控制Exception[/b]
首先他将php的错误通过set_error_handler由自己控制, 通过Exception, Log将错误重新包装,写入相关日志.对其他各种错误也是通过Exception,Log进行处理.
[b]CI的核心点Controller[/b]
Controller有各种关键类的引用, 特别是loader, 可以在方法中加载需要的类. $this->load->module,$this->load->helper, $this->load->libraries, $this->load->database, $this->load->view
尽量只在需要的方法中load, 特别是database.
[b]
CI的数据模式Module类[/b]
Module一般表示关系数据库中的一个表, 相关的数据库操作都可以在此操作, 结果由Controller来获取.Module初始化的时候会将Controller的关键类引用也导入自己的引用,因此他也有loader之类的对象属性
[b]CI的展示层View类[/b]
CI不推荐使用模板引擎, 他本身也有个简单的模板引擎.我也觉得在html中使用原生PHP好过新的模板语言, 一来是模板语言最終还是要转化为PHP,这有个性能问题, 二来嵌入html本就是PHP以前干的事,对前端也不会有太大的困扰,也不会有复杂的逻辑,更不会有业务相关逻辑.
View是通过Controller调用的,因此View里面可以使用$this->load->view()进行页面嵌套, 而Controller其他属性对象如$this->db之类的就不推荐使用了.
Controller将view的结果传到Output类中, 前端控制器调用Output相关方法取出结果返回web服务器
[b]CI的一些问题:[/b]
经过研究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
[/size]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
