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函数放着却不会用。