简述一下你用过的开源框架，说说他们的有缺点？

从语言方面：Tp与Yii都可以满足中文用户的需求，但是由于Yii是国际化的项目，所以代码注释仍旧是英文，不过呢两个框架的创始人依旧都是中国人，所以在交流方面还是挺方便的。

YII优点：

yii呢，自带了一个环境检测脚本，它可以告诉用户当前您的主机环境是否满足yii框架的需求。检测的内容也比较详细，我觉得这一点是非常方便的，yii最低使用php5.1.0，Tp最低5.0。在开发中我使用是一般都是5.3所以两者对我都没有什么区别。

Yii是纯面向对象的框架，而TP提供了一系列单字母函数，相比之下我还是比较更喜欢yii，因为可以避免项目之间的冲突。

冲突例子{

TP在以前的版本【Base基类中】，当时就和一个整合Ucenter时的类冲突了，一度很苦恼。现在TP的各种基类 仍旧是直接命名，如Think 类。在项目开发过程中就会体会命名冲突的痛苦之处。Yii则在框架的类都加上了C 前缀（接口是I前缀），有效地避免了这个问题。Yii中的 CComponent是所有类的基类，可以看看CComponent 的代码，很有用。

说到命名问题了，就不得不说自动导入的问题。TP的类导入和Yii的代码风格差不多。但是Yii还支持PHP的命 名空间和自定义autoload方法。

}

对比：

TP有个特色叫项目编译。我觉得与其使用项目编译，还不如使用APC。在Yii中也有个yiilite.php文件，里面就包含了Yii的所有核心类。Yii作者表示在没有APC的情况下，还是不要使用这个“编译”好的文件，因为反而会增加系统开销。

TP中还在第一次访问的时候自动生成项目，我觉得这一点和自动编译一样，都是我不喜欢的。我对每添加一个if都很敏感，这种判断让我很纠结。比如说 TP在每次运行的时候都要检测PHP版本，而Yii则单独做了一个内容更详细的环境监测脚本。我既然要用这个框架，我在第一次使用的时候，肯定就知道能不 能在当前环境上使用了，为什么要每次都要检测呢。当时我就说过，TP为用户做了太多事情。比如旧版本中的TopN函数。

Yii的组件思路是非常不错的，用起来十分地舒服。从session到cache，你可以无缝地更换所有的组件而无需重构项目。而且Yii的延迟加 载也做得比较彻底，每个组件都是用到的时候才加载。比如，TP中，如果配置了session自动打开，则TP在应用初始化的时候执行 session_start()。而Yii则是你用到session的时候才打开session。

说到项目的配置文件，TP要求是config.php，而Yii则比较灵活，支持多配置文件。

当初TP很推崇自己的ThinkAjax，现在也改用JQuery。这一点是进步。

TP的

动态模型

可以实现不需要定义Model。但是在实际的项目中，我更倾向于使用Yii的方式。顺便说一句，将label定义在model中，为我的日常开发带来了许多方便之处。

刚才提到TP的项目自动生成，Yii中也有这种工具。而且比起TP，Yii的工具更加强大而且可扩展。

从TP的代码中，有人可以看出其作者熟悉JAVA。而从Yii的代码中，有人会发现其作者熟悉.Net。这常常是我身边人看到代码的时候发生的小插曲。

Yii封装了大量的页面控件和类库，也是Yii如此吸引我的一点。这是TP短期无法比拟的，在TP的使用过程中总遇到这样那样的问题，让我感觉TP对我反而是阻碍。而Yii真的是，舒服，实在是太好用了！

无论从代码规范、设计思路、类库丰富程度上来说，TP都远远不及Yii。有人说你看TP多简洁，Yii太臃肿了。错了！简单和简洁不是一回事。TP 那叫简单，你读读Yii的代码吧，那才叫简洁。至于臃肿，去看看Zend Framework就知道了。（顺便说一句，我很喜欢Zend Framework，它是学习设计的典范）

Yii封装了大量的页面控件和类库，也是Yii如此吸引我的一点。这是TP短期无法比拟的，在TP的使用过程中总遇到这样那样的问题，让我感觉TP对我反而是阻碍。而Yii真的是，舒服，实在是太好用了！

无论从代码规范、设计思路、类库丰富程度上来说，TP都远远不及Yii。有人说你看TP多简洁，Yii太臃肿了。错了！简单和简洁不是一回事。TP 那叫简单，你读读Yii的代码吧，那才叫简洁。至于臃肿，去看看Zend Framework就知道了。（顺便说一句，我很喜欢Zend Framework，它是学习设计的典范）

说到读代码。对于程序员真的很难吗？读写得好的代码应该是一种享受才对。Yii的学习曲线是比TP高那么一点点，但是对比Yii的巨大优势而言不算什么了。而且，我认为在遇到学习困难就退缩或者认为Yii就像天书一样的人，还是转行吧。

以上是应一篇评论所写的。对比TP1，现在的TP2的确有了很多进步，但是还是存在一些问题。对比Yii……，TP真的没有可比的能力。抱歉让TP的fans失望了。

那就下定论了吗？不，不是的。从类库到框架，再到解决方案。什么是最好的？每一个人都有不同发说法，这是因为每一个人的思维习惯不同，遇到的问题不同，问题所在的环境也不同。怎么能奢求所有人都有同一个选择呢？

还是那句，适合，就是最好的。对我来说，Yii是最好的。

 

 

 

Yii框架与CI框架比较

Yii

1.模型使用起来比较方便。模型是数据的聚合。对数据进行操作的聚合，业务逻辑的封装。更重要的是模型之间的导航。yii主要定义了四种导航。 has_one belong _to has _many many_to_many 还有另外一个是 stat。通过has_one 可以实现模型的继承。

2.在mvc架构里，有c，有v但是在django里面我却发现只有m和v和t（template），发现这点并不意外，以为我在编写yii代码的 时候发现c和v之间难以权衡，有些东西我情愿写在v里面，有些东西我情愿写在c里面，为的当然是方便，快捷。从复用性来讲，是尚失了复用性但却得到了更大 的灵活和便捷。

3.chtml静态类。推荐大家能尽量使用chtml静态类。能帮我们减少不少时间。chtml:button(‘提交’) 这样子就是一个按钮了 从代码量上面比单纯的html减少了，更重要的是能让我们关注我们需要的部分。chtml::ajaxbutton chtml::link 等等静态方法，都是常用的。 还有一个东西叫做cactiveform，能够根据模型来自动配置表单。并且根据验证规则来自动验证。我也是我所喜欢的。因为不用重复的在写验证规则了。 有些人说这些验证是服务端的验证，有没有客户端的验证？有的 jsformvalite就是这样的一个extension。

 

**** 对MODEL层的指导和考虑较少。文档实例较少

Yii高性能的PHP框架，用于大规模Web应用，Yii采用严格的OOP编写，从MVC，DAO，ActiveRecord，widgets，caching，等级式，RBAC，web服务，到主体化。提供了今日2.0应用开发所需要的几乎一切功能。

优点

纯OOP

模型使用方便

开发速度快，运行速度也快。性能优异且功能丰富

使用命令行工具。

 

缺点：

对Model层的指导和考虑较少

文档实例较少

英文太多

要求PHP技术精通，OOP编程要熟练！

View并不是理想view，理想中的view可能只是html代码，不会涉及PHP代码。

 

【关于CodeIgniter】

优点：

Code Igniter推崇“简单就是美”这一原则。没有花哨的设计模式、没有华丽的对象结构，一切都是那么简单。几行代码就能开始运行，再加几行代码就可以进行输出。可谓是“大道至简”的典范。 配置简单，全部的配置使用PHP脚本来配置，执行效率高；具有基本的路由功能，能够进行一定程度的路由；具有初步的Layout功能，能够制作一定程度的界面外观；数据库层封装的不错，具有基本的MVC功能. 快速简洁，代码不多，执行性能高，框架简单，容易上手，学习成本低，文档详细；自带了很多简单好用的library，框架适合小型应用.

 

缺点：

本身的实现不太理想。内部结构过于混乱，虽然简单易用，但缺乏扩展能力。 把Model层简单的理解为数据库操作. 框架略显简单，只能够满足小型应用，略微不太能够满足中型应用需要.

评价：

总体来说，拿CodeIgniter来完成简单快速的应用还是值得，同时能够构造一定程度的layout，便于模板的复用，数据操作层来说封装的不错，并且CodeIgniter没有使用很多太复杂的设计模式，执行性能和代码可读性上都不错。至于附加的library 也还不错，简洁高效。

 

细节整理

数据库驱动部分的缺陷。

CodeIgniter采用的是动态继承，从而实现了对多数据库的支持。这种方式可以说，比工厂方式要先进得多。

但是，我认为，CodeIgniter的动态继承用反了！

试想一下，如果把驱动作为父类，而CI_DB_driver作为子类，结果会如何？

那么，CI_DB_driver中就可以重写数据库查询，重写获取记录，那可就可以实现对数据CACHE的自动管理与使用。

可是现在，要使用CACHE却只有父类中的query函数，CodeIgniter在帮助中说明，CACHE不支持num_row,不支持num_fields，这不得不说是一大败笔！

 

二、对某些LIBARAY类的看法。

优秀代码本身目的是易于维护，易于扩展，但是CodeIgniter中的一些类，实在不敢恭维，现举两个例子。

第一是图象处理类，其中使用了三套图象驱动，但却将这三套的代码写在一个类中。第二是EMAIL类，做法与是这样。

试想，假如用户只用gd，单凭这一点，用户就需要加载所有的代码，资源开销不论，如果确有意外，要修改，或确有需求要改进，那么，只需要GD的，同样还需要对其它驱动的代码一一过目。这是快速开发，还是浪费用户时间？

试想，一个代码行如此多的类，是易于维护，还是难以维护？

 

三、再谈数据库的cache

数据库的cache，在更新查询后，删除所有的cache文件，这表面上看是没有问题，但是，读取文件时是加锁的。也正因为这一点，文件可能删除不了。然而，cache却没有设置有效期，这就导致了前端显示的数据可能不真实的问题。假如添加了有效期，在读取时，如果发现过期，则立即删除，这样，就是删除不了，那也不读取，这样，也是从数据中查询的新的。这就维护了数据的真实性。可惜的是，CI并没有考虑到这一点。

 

四、数据库类的扩展

懂一点设计模式的人都清楚，动态继承的类不再可以通过继承来进一步扩展。CI给用户提供了一个名为 call_function 函数，让用户扩展。

这种做法，对于初学者而言，或许可以大受欢迎。

但是，这种做法，实际上有很多不雅之处。

第一，扩展函数写在哪里？势必写在全局的helper函数中。

第二，扩展函数如何与数据库类交互？势必要在参数中把当前实例传入。

这种破坏封装的方式，还不如在文档中加上一个扩展实例，新建一个db_ext的类，代理DB类，同时，加上扩展函数。这样在使用时，就没有必要再弄什么函数名与DB对象做为参数了。

这种做法，不仅维护了程序良好的结构。同时，也提升了使用者的水平。但CI并没有这样做，使用这一函数的目的，或许可能是为了迎合初学者吧。但，KOHANA更注重这些，所以，HELPER函数也放到静态类中。这一点CI是值得借鉴的。

五、关于base类

CI的base类针对不同的PHP版本写出不同的代码。其实，网上到处都是PHP4与PHP5中均能运行的单件模式代码。同时，还有更让人不解的，既然BASE实例可以用getinstance得到，为什么还要放到全局中。这种做法，实在让人难以相信，CI代码竟究有多大的可信度（如同cache一样，高要求时，数据一定会不真实的。）。纵有一万个理由，既然单个模式有版本兼容的代码，那么，就应当用上。但是，CI没有这么做。这在某种程度上大大影响了CI的形象。

六、助手函数

CI实质上并没有提供实用的助手函数。比如，美其名为文件名助手，但实际上根本没有什么函数可用，因为，针对文件目录操作的创建，删除，重命名，移动，列出清单这五大操作，文件是五个，目录也是五个，至少是10个函数，这在CI中，是没有提供的。

但若你要仔细查看一下这些助手函数，就会发现，这些函数实际不是提供给用户用的。是CI本身就用到的。

同时，这些助手函数的代码算法仍不敢恭维。比如，求某年某月共有多少天，这么一个小小的问题，原本一行代码就能算出的，CI中却用了很多行代码，并且用上了历法知识。而现成的PHP函数放着却不会用。