从之前的文章Yii源码阅读笔记 - 路由解析 及Yii源码阅读笔记 - Model层实现可以看到Yii框架对于解析好的路由规则及数据表的schema都会根据条件尝试读写缓存 来提高应用性能。
但缓存组件并非核心组件，需要额外的配置，默认ID为cache，如果不使用该ID，那么就得注意同时配置好框架中使用缓存的组件。
恰当地使用缓存组件，能明显地提高应用的性能。
针对不同的缓存后端（backend），Yii框架提供了多种缓存组件，如文件缓存（CFileCache）、Memcached缓存（CMemCache）、Redis缓存（CRedisCache）等。这些缓存组件（除CDummyCache外，CDummyCache并不是一个有效的缓存组件）均直接继承自抽象类CCache（见文件yii/framework/caching/CCache.php）。
下面以使用Memcached缓存为例，分析Yii框架缓存组件的实现。
类CMemcache所在的整个继承树（CMemcache -> CCache -> CApplicationComponent …
通常我们会使用模板引擎来渲染HTML页面，而不是使用HTML代码中插入PHP代码的方式来编写动态页面。Yii框架中模板引擎也是作为组件引入的，默认ID为viewRenderer，
但从Yii源码阅读笔记 - 组件集成可以看到Yii Web应用加载的核心组件中并没有viewRenderer，所以需要自己配置。
Yii提供了一个直接可用的模板引擎组件类CPradoViewRenderer（见文件yii/framework/web/renderers/CPradoViewRenderer.php），该模板引擎类让开发者可以使用类Prado框架的模板语法。
如果你想使用Smarty这种第三方模板引擎，有两种方式将模板引擎引入Yii中使用（以Smarty为例）：
Yii::app()->smarty来调用组件。相比而言，第二种方式更好。原因是：第一种方式由于每种第三方模板引擎的接口不一样，如果应用要替换模板引擎，就需要修改控制器类中的代码。而第二种方式由于第三方组件统一封装成Yii框架定义的模板引擎接口形式， 所以如果要替换模板引擎，只需修改自定义模板引擎组件类的接口实现就可以了。这样调用模板引擎的代码逻辑就只依赖接口形式，而不是依赖于接口实现，从而实现解耦。
本文主要分析第二种方式的实现。
Yii中对页面模板进行渲染可以调用 …
Yii中，对Model层的使用，有两种方式：
第1种方式的示例如下：
<?php
$connection = Yii::app()->db; // 或者Yii::app()->getComponent('db');
$queryResult = $connection->createCommand($sql)->queryRow();
第2种方式中编写的model类可能需要实现方法getDbConnection、model、tableName。
在实现上，第2种方式是基于第1种方式的，即第2种方式的抽象程度更高。Yii没有屏蔽第1种方式，这样能让开发者按需选择。 但我个人并不喜欢这样，两种方式同时存在，会导致应用的model实现稍显混乱。
Yii框架model层的入口为CDbConnection类，该类有很多public的属性可供配置，如connectionString、username、password等。
根据Yii源码阅读笔记 - 组件集成一文可知，组件初始化时会调用init方法。 类CDbConnection的init类实现如下：
public function …Yii框架将各种功能封装成组件，使用时按需配置加载，从而提高应用的性能。内置的组件又分为核心组件与非核心组件，核心组件是任何Web应用和Console应用都需要的。
此外，应用开发者还可以按照一定规则封装配置使用自己的功能组件。Yii会把应用需要的组件都加载到应用容器Yii::app()中，使得组件的使用方式一致方便。
基于Yii框架开发应用需要理解如何配置组件、如何开发自己的组件，对应着需要理解Yii是如何注册加载组件的。
从Yii源码阅读笔记 - 请求处理基本流程一文可知，Yii加载组件的入口为抽象类CApplication构造方法中的以下两行代码：
$this->registerCoreComponents();
$this->configure($config);
registerCoreComponents方法定义于类CWebApplication中，用于加载Web应用的核心组件，组件列表如下：
array(
// 核心组件
'coreMessages'=>array(
'class'=>'CPhpMessageSource',
'language'=>'en_us',
'basePath'=>YII_PATH.DIRECTORY_SEPARATOR.'messages',
),
'db'=>array(
'class'=>'CDbConnection',
),
'messages'=>array(
'class …Yii框架的路由解析功能由核心组件urlManager来完成。路由的形式有两种：
r=controllerID/actionID/controllerID/actionID默认使用get路由形式。由于Yii中controller类命名和action方法都是按照规则命名的，而路由也是按照规则来匹配的，所以完全可以不用额外配置urlManager。
若需要使用path方式，则可如下配置：
"components" => array(
'urlManager' => array(
'urlFormat' => 'path',
'rules' => array(
...
),
),
进一步说明可参考RESTful API设计的一点经验一文。
在“请求处理基本流程”一篇可以看到Yii框架路由解析流程的入口在类CWebApplication的processRequest方法中：
$route=$this->getUrlManager()->parseUrl($this->getRequest());
其中getUrlManager方法定义于类CApplication中，作用是初始化获取URL管理组件（ID为urlManager），实现如下：
public …对于Web框架，我认为其主要有三点作用：
但代价是学习成本 - 为了尽可能发挥Web框架的优势，需要花一些阅读文档，甚至是框架源码（特别是文档缺乏或者文档写得垃圾的），然后经过几次项目实践，一切才能了然于胸。
喏，为了在工作中更好地使用、避免误用Yii框架，大致阅读了Yii框架的部分代码，然后有了这个系列的笔记。
深入学习一个Web框架，首先要理解的是请求处理流程。对于PHP而言，处理流程也即包含了应用的初始化过程，如加载配置、初始化组件等。请求处理流程中最核心的应该是路由解析和分发，此外可能还有过滤器处理、事件处理等，直到请求处理进入具体的Controller和Action。响应生成、过滤等也可以关注。
基于Yii框架的工程目录结构大致如下所示：
软件项目变更的管理和生存之道
个人对这个演讲的印象比较深。演讲者即是最近比较火的《Java程序员修炼之道》一书的作者。
演讲大致以“提出问题 -> 分析问题 -> 解决问题”的思路陈述。
问题是：在软件演化的整个过程中，变化是始终存在的。如：
这些变化可能会导致两个问题的发生：
“变化”导致的问题，说到底是人为造成：
No matter what …
2013已经过去了。
时间消逝得太快，以至于很多事情在记忆上相互重叠，无法明确区分事情发生的时间点。那么该如何回顾这过去的一年？
2013，参加工作的第一年，我几乎全身心地扑在工作上，自认为做了一些事情，也有很多收获，愉快而充实。技术工作于我而言，更多的 是一种兴趣、乐趣。
非常感谢领导、导师以及伙伴。领导、导师给了我很大的空间，导师始终耐心地给于业务和技术的指导，和伙伴的合作非常愉快。
这一年，如果说我有了些许成长进步，很大程度上归功于他们。
这些话说得也许有些像获奖感言，却是发自我的真心。
2013，我和老婆，订婚、领证，终于结束了长达5年的异地恋，从此以后会有个人始终和我“相依为命”，面对或许琐碎的每一天，在城市飘荡的 日子也不会再孤单，我很安心，很踏实。
现在，我没车、没房，每个月的工资也不算高，但我始终在努力，除了为自己，还因为有个人值得你去努力把生活过得更好。
为了记录我们以前和以后人生中的重要时刻，我特意创建了一个大事年表网页 …