国外主流PHP框架比较



国外主流PHP框架比较


作者:heiyeluren
博客:
http://blog.csdn.net/heiyeshuwu
时间:2008-5-5

最近简单的使用了目前在国内用的比较多的几个主流国外PHP框架(不包括国内框架),大致对这些框架有个直观上的感受,简单分享一下,对于哪些做框架选型的时候,权当一个参考。
主要参考的框架包括:CodeIgniter、CakePHP、ZendFramework、Symfony

说明:我对很多框架也没有认真使用,只是简单试用了一下,可能很多看法不成熟或者是错误的,请大家指正,一起成长。 :-)


【 CodeIgniter 】

官方网站:http://codeigniter.com
中文网站:http://codeigniter.org.cn
中文手册:http://codeigniter.org.cn/user_guide
视频教程:http://codeigniter.org.cn/tutorials
测试版本:CodeIgniter_1.6.1

优点:
1. 配置简单,全部的配置使用PHP脚本来配置,执行效率高;具有基本的路由功能,能够进行一定程度的路由;具有初步的Layout功能,能够制作一定程度的界面外观;数据库层封装的不错,具有基本的MVC功能
2. 快速简洁,代码不多,执行性能高,框架简单,容易上手,学习成本低,文档详细;自带了很多简单好用的library,框架适合小型应用

缺点:
1. 把Model层简单的理解为数据库操作
2. 框架略显简单,只能够满足小型应用,略微不太能够满足中型应用需要

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

 

【 CakePHP 】

官方网站:http://www.cakephp.org
中文手册:http://www.1x3x.net/cakephp
视频教程:http://search.you.video.sina.com.cn/s?key=cakephp
测试版本:cake_1.1.19.6305

优点:
1. CakePHP是最类似于RoR的框架,包括设计方式,数据库操作的Active Record方式;设计层面很优雅,没有自带多余的 library,所有的功能都是纯粹的框架,执行效率还不错;数据库层的 hasOne, hasMany 功能很强大,对于复杂业务处理比较合适;路由功能,配置功能还不错;自动构建脚手架(scaffold)很强大;适合中型应用;基本实现过了MVC每一层;具有自动操作命令行脚本功能;
2. 文档比较全,在国内推广的比较成功,大部分都知道CakePHP,学习成本中等

缺点:
1. CakePHP非常严重的问题是把Model理解为数据库层操作,严重影响了除了数据库之外的操作能力
2. CakePHP的cache功能略显薄弱,配置功能稍嫌弱;CakePHP不适合大型应用,只适合中型应用,小型应用来说略微的学习成本高了点

评价:
总体来说CakePHP框架代表了PHP框架很重要的一个时代和代表,并且目前发挥着很重要的作用,不少自己写的框架都模仿了CakePHP的方式,是个里程碑式的产品;CakePHP透露着RoR的敏捷开发方式和把数据库操作认为是唯一Model的设计思想,作为开发快速应用和原型是绝好的工具;同样,用来做Web2.0网站的开发框架,也是值得选择的。


【 Zend Framework 】

官方网站:http://framework.zend.com
中文手册:http://www.phpeye.com/zf
视频教程:http://framework.zend.com/docs/screencasts
测试版本:ZendFramework-1.5.0

优点:
1. 官方出品,自带了非常多的 library,框架本身使用了很多设计模式来编写,架构上很优雅,执行效率中等;MVC设计中,比较简洁,具有路由功能,配置文件比较强大(能够处理XML和php INI),各种 library 很强大,是所有PHP框架中各种功能最全面的,包括它不仅是一个框架,更是一个大类库(取代PEAR),这是它的主要特色;能够直观的支持除数据库操作之外的Model层(比 CodeIgniter 和 CakePHP 强),并且能够很轻易的使用Loader功能加载其他新增加的Class;Cache功能很强大,从前端Cache到后端Cache都支持,后端Cache支持Memcache、APC、SQLite、文件等等方式;数据库操作功能很强大,支持各种驱动(适配器)
2. 文档很全,在国内社区很成熟,并且目前不少Web 2.0网站在使用,学习成本中等

缺点:
1. MVC功能完成比较弱,View层简单实现(跟没实现一样),无法很强大的控制前端页面
2. 没有自动化脚本,创建一个应用,包括入口文件,全部必须自己手工构建,入门成本高
3. Zend Framework 作为一个中型应用框架问题不大,也能够勉强作为大型应用的框架,但是作为一个很成熟的大型PHP框架来说,还需要一些努力

评价:
作为官方出品的框架,Zend Framework的野心是可以预见的,想把其他框架挤走,同时封装很多强大的类库,能够提供一站式的框架服务,并且他们的开发团队很强大,完全足够有能力开发很强大的产品出来,所以基本可以确定的是Zend Framework前途无量,如果花费更多的时间去完善框架。同样的,Zend Framework架构本身也是比较优雅的,说明Zend官方是有很多高手的,设计理念上比较先进,虽然有一些功能实现的不够完善,比如View层,自动化脚本等等,这些都有赖于未来的升级。总体来说Zend Framework是最值得期待的框架,当然,你目前要投入你的项目中使用也是完全没问题的。

 

【 Symfony 】

官方网站:http://www.symfony-project.org
中文网站:http://symfony-project.cn
权威指南:http://www.symfony-project.org/book
学习参考:http://sf.thecodecentral.com
测试版本:symfony-1.0.13

优点:
1. Symfony 是我了解的PHP框架中功能最强大的,而且我使用时间比较长,但是很多功能还是没有挖掘出来;它完整实现了MVC三层,封装了所有东西,包括 $_POST,$_GET 数据,异常处理,调试功能,数据检测;包含强大的缓存功能,自动加载Class(这个功能很爽),强大的i18n国家化支持;具有很强大的view层操作,能够零碎的包含单个多个文件;非常强大的配置功能,使用yml配置能够控制所有框架和程序运行行为,强大到让人无语;能够很随意的定义各种自己的class,并且symfony能够自动加载(auto load)这些class,能够在程序中随意调用;包含强大的多层级项目和应用管理:Project --> Application --> Module --> Action,能够满足一个项目下多个应用的需要,并且每层可以定义自己的类库,配置文件,layout;非常强大的命令行操作功能,包括建立项目、建立应用、建立模块、刷新缓存等等;
2. Symfony绝对是开发大型复杂项目的首选,因为使用了Symfony,将大大节约开发成本,并且多人协作的时候,不会出现问题,在Project级别定义好基础Class以后,任何模块都能够重用,大大复用代码

缺点:
1. 数据库操作model采用了重量级的propel和creole,不过在我测试的版本中已经把他们移到了addon里,可用可不用
2. 缓存功能无法控制,每次开发调试总是缓存,需要执行 symfony cc, symfony rc 来清除和重建缓存;
3. 效率不是很高,特别是解析模板和读取配置文件的过程,花费时间不少;
4. 学习成本很高,并且国内没有成熟的社区和文档,连中文手册都没有,相应的要掌握所有功能,需要花费比较多的时间

评价:
Symfony绝对是企业级的框架,唯一能够貌似能够跟Java领域哪些强悍框架抗衡的东西;强悍的东西,自然学习复杂,但是相应的对项目开发也比较有帮助,自然是推荐复杂的项目使用Symfony来处理,觉得是值得,后期的维护成本比较低,复用性很强。相应的如果使用Symfony的应该都是比较复杂的互联网项目,那么相应的就要考虑关于数据库分布的问题,那么就需要抛弃Symfony自带的数据库操作层,需要自己定义,当然了,Symfony支持随意的构造model层。

 


【 总评 】

以上数款框架,各有特色,而且都是开源项目,不过框架针对的项目不一样,一般来说 CodeIngiter 比较适合小型项目,CakePHP 和 Zend Framework 比较适合中型项目,Symfony  比较适合大型重量级项目,在项目选型的时候,要充分考虑框架的可以定制性、扩展性,因为每个项目都无法确定你是否会随着需求的变化进行改变。

相对来说,Zend Framework 和 Symfony 应对变化的能力比较强,特别是能够随意定制 model 层的Class,能够非常方便增加自己业务或者数据处理类,我是个人比较推荐在中大型项目中使用的框架。CodeIngiter 和 CakePHP 在中小型项目中同样能够发挥重大作用,快速开发和原型构建,非常适合目标不清晰的原型项目的开发。了解一个框架最好的方式就是使用它,学习它最好的方式就是看视频。:-)

仁者见仁,智者见智,在项目挑选框架的时候,请先认真考察项目的需求和未来的变化,然后选择合适的框架,让项目开发速度和后期维护性得到一个合理的平衡,当然了,也许,自己写一个框架更适合。 :-)

泛泛的评价了几款框架,估计很多东西都没有说到点子上,大家就姑且看之,同样欢迎提出看法指正!

 

发表于 @ 2008年05月05日 17:31:00|评论(28)|收藏

新一篇: [转] Mosix:强大的集群Linux方案 | 旧一篇: 另外五个 PHP 设计模式

评论

# Jio 发表于2008-05-06 11:24:26  IP: 58.49.112.*
作者对Zend Framework的描述中,有一个地方我不是太赞同
Zend Framework自带的view的确是功能非常有限,但是它提供了非常方便的接口,可以非常方便的使用其他的模板引擎,Zend Framework官方的文档中,就提供了完整的将smarty和Zend Framework集成的接口类。所以我觉得,Zend Framework只所以不将view做的那么完整,有很大的原因是已经有了功能很强大的、php官方支持的smarty的原因。
# test 发表于2008-05-06 12:41:18  IP: 118.26.231.*
Symfony 可以把缓存功能关闭,就不用cc了
# heiyeshuwu 发表于2008-05-06 13:13:49  IP: 125.120.164.*
回复Jio:
我说的view层不仅仅是模板功能,基本上上面说的框架都模板功能,view层还有很多东西,比如对layout的支持重用,支持类似symfony中 component 和 partial 的功能,其实如果一般框架中使用了模板系统(Smarty之类),性能下降的更厉害,所以大家都不用
# heiyeshuwu 发表于2008-05-06 13:14:53  IP: 125.120.164.*
回复 test :
据我测试经验,我反复尝试了关闭所有的cache功能都还是存在需要cc的过程,不知道是不是symfony的bug
# hbgth 发表于2008-05-06 13:55:13  IP: 221.232.130.*
那smarty呢??? 难道不算一个重量级的吗??
# Jio 发表于2008-05-06 13:58:18  IP: 58.49.112.*
回复heiyeshuwu:
symfony我还没有用过,所以也没有办法评论其好坏,不过通过作者的介绍,我倒是对它很有兴趣,有时间一定研究一下。
不过作者说“使用了模板系统(Smarty之类),性能下降的更厉害,所以大家都不用”,我觉得也并非完全如此。
至少我所做的项目和我看到的一些其他组织或公司做的项目和软件,不管大小,很多都用模板技术的。
就拿smarty来说,他使用了缓存的机制,第一次使用那个效率比较低之外,之后使用的效率还是非常的高的。
# kenzen 发表于2008-05-06 16:39:40  IP: 210.13.101.*
CakePHP非常严重的问题是把Model理解为数据库层操作,严重影响了除了数据库之外的操作能力

不是很理解你的这个说法
# rivalhw 发表于2008-05-06 16:48:30  IP: 59.46.120.*
框架让让一部分人从繁琐的事物逻辑解放出来,但却让另外一大部分人变得迷茫和轻浮...
# test 发表于2008-05-06 17:02:57  IP: 118.26.231.*
对于 Symfony 中应用级别的 yml 文件(app.yml, validate.yml ...), 只要把 cache 关了就不用每次 cc 了,除非你每次调试都涉及到修改系统级别的 yml 文件,如 settings.yml, factory.yml ...
# test 发表于2008-05-06 17:13:51  IP: 118.26.231.*
Symfony 启动时初始化的性能损耗不大(和一般的MVC框架差不多),主要性能瓶颈在数据库层(默认是Propel)上,不过可以通过一些合适的缓存机制来进行弥补。关于读取配置文件的性能优化,可以在生产环境中使用插件 sfOptimizer 来把那些配置数据硬编码进行替换,速度就快多了。
# Haohappy 发表于2008-05-07 04:04:20  IP: 77.56.157.*
关于Zend_View,黑夜可以看到Zend_Layout和Zend_View的helper部分,应该算是很强大的。你所说的layout重用,是完全可以的。
# heiyeshuwu 发表于2008-05-07 19:22:03  IP: 60.177.58.*
to Jio:
一般内部的MIS,OA系统来说,一般性能差一点可以忍受,对于互联网项目来说,并发访问大,性能非常重要,有时候缓存只是针对数据层来缓解,如果要从模板层缓解,那么这个成本就比较高,开发成本也提高,反而得不偿失。
# heiyeshuwu 发表于2008-05-07 19:23:53  IP: 60.177.58.*
to kenzen:
就是说CakePHP把数据库操作当作缺省唯一操作,其实我们的数据来源不只是数据库,可能是文件系统、远程的XML、或者内存,CakePHP的设计方式更多是针对数据库结构的项目。
# heiyeshuwu 发表于2008-05-07 19:25:28  IP: 60.177.58.*
to test :
就我使用来说,symfony确实怎么都无法关闭模板的cache功能,不知道是啥原因。
至于symfony的Propel层是可以很轻易的替换,这个也是我很推荐Symfony的缘故,呵呵,很容易构造各种Model层,丝毫不影响。
# heiyeshuwu 发表于2008-05-07 19:30:42  IP: 60.177.58.*
to Haohappy:
总体来说,感觉Zend framework 在view层做的不够好,只是作为一个官方框架来说,需要好好向其他框架学习,呵呵。
# wqh_2008 发表于2008-05-07 20:03:35  IP: 121.23.165.*
相互吸取精华——一个目标提高工作效率,缩短开发周期,提高软件质量、、、希望zend framework继续发展
# 三马 发表于2008-05-08 19:44:22  IP: 222.71.181.*
symfony 的配置文件本身就是生成在cache里面的,读取以后才能运行,当然是无法关闭的。在dev的环境下缓存每次都会生成的,也不影响调试,不需要 symfony cc。

路人,你的blog为什么在我的google reader里面没法显示新文章?别人有没有这个问题?
# heiyeluren 发表于2008-05-09 17:05:40  IP: 125.122.48.*
to: 三马
俺不知道耶,呵呵,咔咔,也许是csdn的rss刷新的不及时。。。
# leafor 发表于2008-05-23 17:36:17  IP: 221.225.246.*
支持一下啊。
# 学习笔记 发表于2008-06-03 21:48:28  IP: 116.232.122.*
很是不错的文章啊,我是很想学习cakephp,搜索了几天相关的文章,能找到的也就只有老王写的一些日记不错,其它我就没找到有关cakephp的学习资料,现在我想从写一个小网站入手,但真的不知道第一步因应怎么走啊。
# 冰河 发表于2008-06-23 12:42:44  IP: 219.142.128.*
MODEL模型,即业务对象模型。主要由两部分构成:业务对象(BO)和业务对象的访问处理方法(通常是DAO),在ORM环境中,业务对象其实就是数据库表的映射,称之为持久化对象(PO)。BO/PO应该是最简单的数据结构,不应该在其内部做任何业务处理(比如一个商品自身不会处理任何业务,生产、销售应该给车间和市场部去做)。

在MVC中,通常需要将CONTROLLER分离为流程控制和业务逻辑两部分。由DAO管理MODEL的注册和访问(现在比较流行在应用和数据库间加一个ORM)。

这样实际的MVC应用,通常涉及以下具体的结构:
VIEW
CONTROLLER
BUSINESS(SERVICE)
MODEL
DAO、(ORM)
------------------------
而BO/PO侧贯穿整个生命周期
也有人会在VIEW层基于BO/PO再次构建更加符合视图使用需求的视图对象-“VO”,例如STRUTS的ACTIONFORM。但是本人不建议那么做-已经够麻烦了。
# 冰河 发表于2008-06-23 12:48:33  IP: 219.142.128.*
SORRY,应该去掉一个词MODEL

VIEW
CONTROLLER
BUSINESS(SERVICE)
DAO、(ORM)
------------------------
BO/PO
# zz 发表于2008-08-01 11:20:56  IP: 61.172.247.*
再介绍个框架
diggmore,
是基于ZF写的,封装了很多东西...
不过这只是内部代号,据说写出来后,懒的推广了...
他们几乎是写了自己用的 www.7yes.com
有次跟他们沟通的时候,看了下源码,的确很强大....
适合大网站的部署构架的了
有兴趣可以去找找资料看看~ 呵呵
# zz 发表于2008-08-01 11:21:59  IP: 61.172.247.*
再介绍个框架
diggmore,
是基于ZF写的,封装了很多东西...
不过这只是内部代号,据说写出来后,懒的推广了...
他们几乎是写了自己用的 www.7yes.com
有次跟他们沟通的时候,看了下源码,的确很强大....
适合大网站的部署构架的了
有兴趣可以去找找资料看看~ 呵呵
# zz 发表于2008-08-01 11:22:20  IP: 61.172.247.*
再介绍个框架
diggmore,
是基于ZF写的,封装了很多东西...
不过这只是内部代号,据说写出来后,懒的推广了...
他们几乎是写了自己用的 www.7yes.com
有次跟他们沟通的时候,看了下源码,的确很强大....
适合大网站的部署构架的了
有兴趣可以去找找资料看看~ 呵呵
# zz 发表于2008-08-01 11:22:23  IP: 61.172.247.*
再介绍个框架
diggmore,
是基于ZF写的,封装了很多东西...
不过这只是内部代号,据说写出来后,懒的推广了...
他们几乎是写了自己用的 www.7yes.com
有次跟他们沟通的时候,看了下源码,的确很强大....
适合大网站的部署构架的了
有兴趣可以去找找资料看看~ 呵呵

以下是对提供的参考资料的总结,按照要求结构化多个要点分条输出: 4G/5G无线网络优化与网规案例分析: NSA站点下终端掉4G问题:部分用户反馈NSA终端频繁掉4G,主要因终端主动发起SCGfail导致。分析显示,在信号较好的环境下,终端可能因节能、过热保护等原因主动释放连接。解决方案建议终端侧进行分析处理,尝试关闭节电开关等。 RSSI算法识别天馈遮挡:通过计算RSSI平均值及差值识别天馈遮挡,差值大于3dB则认定有遮挡。不同设备分组规则不同,如64T和32T。此方法可有效帮助现场人员识别因环境变化引起的网络问题。 5G 160M组网小区CA不生效:某5G站点开启100M+60M CA功能后,测试发现UE无法正常使用CA功能。问题原因在于CA频点集标识配置错误,修正后测试正常。 5G网络优化与策略: CCE映射方式优化:针对诺基亚站点覆盖农村区域,通过优化CCE资源映射方式(交织、非交织),提升RRC连接建立成功率和无线接通率。非交织方式相比交织方式有显著提升。 5G AAU两扇区组网:与三扇区组网相比,AAU两扇区组网在RSRP、SINR、下载速率和上传速率上表现不同,需根据具体场景选择适合的组网方式。 5G语音解决方案:包括沿用4G语音解决方案、EPS Fallback方案和VoNR方案。不同方案适用于不同的5G组网策略,如NSA和SA,并影响语音连续性和网络覆盖。 4G网络优化与资源利用: 4G室分设备利旧:面对4G网络投资压减与资源需求矛盾,提出利旧多维度调优策略,包括资源整合、统筹调配既有资源,以满足新增需求和提质增效。 宏站RRU设备1托N射灯:针对5G深度覆盖需求,研究使用宏站AAU结合1托N射灯方案,快速便捷地开通5G站点,提升深度覆盖能力。 基站与流程管理: 爱立信LTE基站邻区添加流程:未提供具体内容,但通常涉及邻区规划、参数配置、测试验证等步骤,以确保基站间顺畅切换和覆盖连续性。 网络规划与策略: 新高铁跨海大桥覆盖方案试点:虽未提供详细内容,但可推测涉及高铁跨海大桥区域的4G/5G网络覆盖规划,需考虑信号穿透、移动性管理、网络容量等因素。 总结: 提供的参考资料涵盖了4G/5G无线网络优化、网规案例分析、网络优化策略、资源利用、基站管理等多个方面。 通过具体案例分析,展示了无线网络优化中的常见问题及解决方案,如NSA终端掉4G、RSSI识别天馈遮挡、CA不生效等。 强调了5G网络优化与策略的重要性,包括CCE映射方式优化、5G语音解决方案、AAU扇区组网选择等。 提出了4G网络优化与资源利用的策略,如室分设备利旧、宏站RRU设备1托N射灯等。 基站与流程管理方面,提到了爱立信LTE基站邻区添加流程,但未给出具体细节。 新高铁跨海大桥覆盖方案试点展示了特殊场景下的网络规划需求。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值