加载中…
正文 字体大小:

Yii框架与CI框架比较

(2013-05-22 14:28:49)
标签:

php框架

yii学习

yii

ci

codeigniter

分类: Yii框架学习

Yii

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

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

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

 

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

Yii高性能的PHP框架,用于大规模Web应用,Yii采用严格的OOP编写,从MVCDAOActiveRecordwidgetscaching,等级式,RBACweb服务,到主体化。提供了今日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

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

 

六、助手函数

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

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

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


原文来至:http://aipanshi.com/post/18.html

0

阅读 评论 收藏 转载 喜欢 打印举报
已投稿到:
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有