CI源码(一)—config配置文件

(一) 使用方式

(a) 系统级配置

语言、字符编码、session、cookie等配置项

• 文件位置: application/config/config.php
• 加载方式: 自动加载
• 调用方式: $this->config->item(‘config_item_key‘);

(b) 业务级别配置

实际业务中用到的配置项，或者叫做常量，比如1<->男  2<->女  3<->未知等数据。强烈建议把业务级别的配置项与系统配置项分开。CI支持多级目录的配置文件加载，所以可以在application/config文件夹下建立专门的业务配置文件夹, 例如constants.

• 文件位置: application/config/path/to/config_file.php
• 加载方式: 手动加载(或者在autoload.php中配置自动加载).$this->config->load(‘path/to/config_file’, true).第二个参数，会把不同文件的配置分组, 强烈建议加上.
• 调用方式:  $this->config->item(‘config_item_key’, ‘path/to/config_file’); 第二个参数是上面加载的时候指定的分组

(c) 动态修改配置

CI所有的配置项都是一次加载，同时也支持动态修改配置项。但是暂时不支持指定分组的配置项修改，我自己实现了, 地址:https://github.com/wkupaochuan/analysis-about-ci-frame.git, 路径是application/core/MY_Config.php

• 单个修改: $this->config->set_item(‘config_item_key’, $value);
• 批量修改: $this->config->_assign_to_config($array);

(二) 实现方式

(a) Common.php

这个文件中都是全局可以调用的方法，跟config相关的是get_config方法和config_item函数, 主要用在system的框架文件中

• get_config: require文件application/config/config.php文件，保存在局部静态变量$_config中，所以也是一次加载。这里需要注意的是因为加载的是必须的配置文件config.php，所以使用了require，来进行错误处理
• config_item: 获取加载过的配置项

(b) system/core/config.php 类

这个类实例化后作为超类CI的一个属性$this->config, 主要方法__construct()、load()、item(), 配置文件加载后赋值给config对象的属性$config, 因为超类CI是全局的，所以这里的配置文件也是一次加载

• __construct: 默认先加载application/config/config.php文件，调用Common.php文件中的函数get_config
• load: 根据传入的参数$file，分别在config/ENVIRONMENT/$file和config/$file中寻找目标配置文件，优先加载当前ENVIRONMENT下的配置文件。找到配置文件后会把对应的配置数组merge到已经加载的配置中。这里要十分注意，一旦两个不同的配置文件中存在相同的配置key，又没有指定配置项分组，前面加载的配置项就会被覆盖，所以强烈建议，每次load配置文件都指定第二个参数use_section
• config_item: 返回已经加载的配置项, 没找到(确实没有的配置项和未加载的配置项)则返回false。

(三)优缺点

(a) 缺点

• 每次使用$this->config->item()，获取配置项时，有可能因为没有load过对应的配置文件，所以建议load then item, 或者全部配置文件都配置上autoload。这里我自己实现了一个my_item方法my_item($file, $item), 不需要先加载后调用。方法内部会先调用，没有结果会尝试加载一次，然后再次调用并返回结果，一定程度上简化了代码, 而且不需要配置autoload。路径是application/core/MY_Config.php。

(b) 优点

• 支持目录分级, 方便清晰的组织、管理业务配置文件

ci框架源码分析地址https://github.com/wkupaochuan/analysis-about-ci-frame.git