看到框架内很多地方都是一个普通的请求，另一个是…ajaxResponse…的。
比如CWebUser里边的loginRequired 和 loginRequireedAjaxResponse
比如例子里给出的很多 action 方法，既要处理普通请求，又要处理ajax请求，既要做model的展示功能，又要做model的保存.
项目一点点变复杂的时候，是不是要拆开这些东西呢？
看到框架内很多地方都是一个普通的请求，另一个是…ajaxResponse…的。
比如CWebUser里边的loginRequired 和 loginRequireedAjaxResponse
比如例子里给出的很多 action 方法，既要处理普通请求，又要处理ajax请求，既要做model的展示功能，又要做model的保存.
项目一点点变复杂的时候，是不是要拆开这些东西呢？
目前已经是最佳状态了 不必在分. 拿简单的user模型的curd方法来说。
早期不用yii 用普通的php实现那么可能需要写的脚本：
user/creat.php user/doCreate.php
user/edit.php user/doEdit.php
其中不带do的脚本只负责form渲染 而真正处理表单数据入库的是doXXX 脚本 这就是你说的显示 与处理请求分离 但带来的坏处是 脚本很多 代码冗余。
其实一个create.php 就可以处理表单渲染跟post创建功能 区别只在是不是POST请求 这样就可以去掉doCreate.php 脚本 在脚本人口判断是否是POST请求(if(isset($_POST[…]))); 再往下走 发现update（即edit功能）表单也出现了相同的部分 为了复用 在yii中可以看到又出现了 共用现象 即create 跟 update 同享 form.php视图 这是进化过来的 不是一上来就设计成这个样子。
还有请求区分ajax问题 这个主要在ajax翻页上 CGridView和CListView 可以开启ajax翻页或者关闭此功能。但最终处理是一样的。 在用传统php来做 ajax请求可能返回的是html片段 但yii中不是这样的 仍旧返回的是完整页面 只是局部替换了下（打开firebug 看gridview或者listview在ajax翻页时返回的数据） 这一块可能有些不必要的数据由server端渲染 但带来了简单一致性 但也是有优化的地方 比如是ajax请求时就不必渲染布局了
为啥那么多人说yii是实战性项目 就是因为他们做过几个项目后发现最终进化的东西跟yii几乎不谋而合
好吧，仔细看了 blog 教程。
PostController 中的 newComment() 方法印象深刻。
这也算是一种设计模式，值得学习。谢谢哈哈。