一个懒人专用文章归档神器,如果你不能成为压路机的一部分,那么你就只能成为道路的一部分 Bala~bala~

TP YII CI框架对比

php 懒人 1585℃ 0评论

Thinkphp CI YII框架对比

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

从语言方面: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函数放着却不会用。

转自:http://blog.csdn.net/pangchengyong0724/article/details/49246847

转载请注明:懒人档案室 » TP YII CI框架对比

喜欢 (0)
发表我的评论
取消评论
表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址