php框架 - Laravel vs CakePHP vs CodeIgniter 的看法(性能,开发效率,负债能力)
PHP中文网
PHP中文网 2017-04-10 14:58:27
0
17
1677

最近打算用做一个比较中型的PHP应用,想到用比应用广泛的MVC框架。
要求

1.支持命名空间
2.不支持PHP4
3.架构、性能更重要
4.长期稳定,而不是很快就会被淘汰或者解散的框架

Yii2、symfony2都太庞大,不适合。考虑到了Laravel CakePHP Kohana CI。
先说一下自己对这三款框架的看法

1) CI 2.x
    官网一种放弃状态
    CI框架太轻巧,很多东西都要自己做,非常陈旧
    CI框架在IDE中无法进行代码跟踪,点击类名无法跳转过去

2) CakePHP 2.x
    为什么非得向下兼容PHP4?弄得非得用一个蹩脚的App::use()来替代namespace!
    为了兼容PHP4弄得整个架构乱七八糟
    如果CakePHP放弃对PHP4的兼容,应该会有更多的人使用

3) Laravel
    不支持php4,支持命名空间
    网上非常多的好评,仔细看每个评测文章都是复制粘贴的感觉很枪手。

网上包括segmentfault上都有对框架的比较,但基本上是都是摘抄的转载的,而不是自己使用过后的真实体会,期待有使用过后的真实体会,而不是复制粘贴网上人云亦云的测评。


今天使用Laravel,发现文档不是官方宣传的那样丰富,而是少非常不清晰。
Route的所有方法有那些,根本就找不到这些说明。官方的文档只是几个简单的例子,根本就不详尽。


2015-6-16 补充:
再次回到这个问题,我已经一路使用了CodeIgniter、ThinkPHP 再到Yii2,开发了一些完整的项目。现在发觉 PHP 的 MVC 模式确实难以满足需求,到后来的 component,现在再到laravel的思路,难以理解,总是一直感觉在追赶,特别疲惫。

其实一开始,我走过太多的弯路,很多年以前,对于OOP都有着强烈的排斥和极端的抵触,原因就是使用了class 类会导致程序运行非常慢,究其根本是我使用的运行环境实在是太烂了,虚拟主机都不如,而且还是win。到后来MVC模式,加载的文件数目几乎是无法比拟。后来开始使用MVC框架,普通的主机已经完全无法支撑,绝大部分虚拟主机大部分都是win服务器、而且PHP最多最多PHP5.3就不错了,还有很大一批居然还在PHP5.0(虚拟主机就是只提供一个FTP用户名密码的那种)。

走过太多的弯路,一直以来总是被硬件条件、运行环境束缚思维。

PHP中文网
PHP中文网

认证高级PHP讲师

reply all(17)
洪涛

CakePHP没用过不予置评。

一个php程序员的成长过程往往可以类比成 CI -> Laravel -> CI。CI和Laravel基本可以认为是过去几年和现在两个时期的PHP框架霸主,使用率最高的框架。CI适合完全新手和高手,Laravel适合中级别程序员提高生产力。

详解

CI提供的东西少,恰恰是其立于不败之地的最重要的原因。

另外,CI的文档简直就是开源软件的典范,非常之清晰、详尽!

它能给我们最核心的功能,让我们真正感悟php做web的精髓,感受MVC的真正魅力。BTW,不要小看MVC,它作为现代GUI软件开发久经考验的最流行结构,不是在还没用过MVC时候看两眼描述就能理解的,我们需要去做,去感受。


Laravel号称完全模仿Rails,不得不承认他们做到了,包括性能。^_^ Laravel其实是符合互联网产品的开发特点的:迅速做出可用产品,再高速迭代。

如果你用了Laravel,也不用担心性能问题,因为当出现性能问题的时候,性能也就不是问题了。有用户有钱有时间,想怎么重构怎么重构,妥妥的~

大家讲道理

你的分析很多都是错的.

(1) EllisLab确实曾经想找人接盘CI, 但事实上, github上CI的更新一直没停过.

(2) cakephp 2.x只支持php 5.x, 并不支持php 4.x, 支持php 4.x的是cakephp 1.x, cakephp 2.x不用命名空间是因为命名空间是php 5.3后才有的, 而原先php社区的计划是把这些特性放到php 6里. 仅支持php 5.4的版本是cakephp 3, 马上要出正式版了. 如果你优先看中长期稳定的话, cakephp肯定是首选, 它到现在还在维护仅支持php 4.x的cakephp 1.x版的bug修正.

(3) 如果你认为yii2和symfony算大的话, Laravel你就不该考虑, 这东西是构建在大量symfony components上的, 不过大小真有那么重要么? 现在也并不是10多年前1MB空间1~2RMB的时代了, 不是么?

小葫芦

7月20日更新:最新的Yii2已经原生支持读写分离,支持一个写数据库和多个从数据库。也支持多个写库多个从库!

不赞同题主关于Yii2庞大的说法,Laravel算上他依赖的第三方代码,比Yii2文件多的多。况且仅仅从一个文件多少就来断定一个框架是否庞大是非常肤浅的。

事实上Yii2本身非常灵活,绝大部分的组件是可被替换掉的。你可以阅读一下他们最新的文档,Yii2本身就可以单独的嵌入到你原有的代码里去,你想用AR就载入AR组件(事实上这个功能在Yii1时代就提供了,当初我就在本自有项目里非常容易的用到了Yii1的model组件,不过由于之前的架构实在过于混乱加上一些其他缘故,最终放弃了该项目)。

Yii2本身功能完善,而且一直在积极吸收其他框架优秀的特性,比如symfony2的AssetBundle、WebDebug都是非常实用的功能。然后是后台神器Gii+GridView这两个组件,应付大多数后台开发就是简单的点两下,改改就OK了,还有DataProvider这个组件也非常实用。总之大部分web开发中要用到的功能Yii都帮你提供了现成的,你只需要用就好了,不好用就继承一个改改,然后在配置里将他替换掉就OK了。

然而在提供如此多功能的前提下,Yii2的性能居然不差,我已经有两个项目是基于Yii2的,其中一个日均pv在300W左右,完全无压力。很多第三方的测试也显示Yii框架的性能一直名列前茅(yaf、phalcon这些用C写的就另算了,CI功能太简单,我觉得拿他来比较不合适)

当然,Yii2也不是没有问题,就目前我遇到的一个情况就是某些地方组件的耦合度有点高,比如yii\web\User这个类,他为了最大限度的提升开发效率,跟ActiveRecord耦合的有点高,在web上这当然没问题,但现在移动开发当道,这个就有点不适合了,需要自己改一些东西。

另外一个就是框架本身缺少数据分层的支持,所有跟数据库打交道的东西都是ActiveRecord。而由于Yii2提供的ActiveRecord非常易用,很容易就导致滥用,我其中的一个项目就是这样滥用过,很多类似这样的代码$user = User::findOne($uid);直接就写在了controller里,醒悟过来后花了不少时间来处理。

当然怨念最深的就是号称为web2.0而生的框架,居然从1到2都没有官方支持的读写分离功能,这点实在说不过去。

最后Phalcon绝对是神器!http://phalconphp.com

大家讲道理

Laravel的核心思想是IoC和Facades,要实现这两个思想就难免需要大量的抽象类,一个框架好不好要综合来看,整体看来Laravel还是非常优雅的,尽管为了实现Facades使用了一些__call魔术方法,但这样就非常完美的解决了耦合问题,我觉得没有一定的大型网站开发经验很难真正的体会解耦的重要性,因此相比性能,业务的耦合度要重要得多,其实代码本身都不复杂仔细去分析几个核心文件你就会豁然开朗,推荐一篇文章,说得很细http://www.yuansir-web.com/?p=1012&preview=true

我个人觉得现在的框架主要分两种,一种是纯MVC的,CI是典型代码,很多程序员自己写的框架都是受CI的影响,我个人就是深受CI的影响,因此在自己的项目里面自己写的框架基本可以算作是CI的核心剥离,去除了不需要的兼容性和国际化的部分,但是经过了一些大型项目之后,我发现现有的MVC已经远远不能满足我对业务的需求,复杂的代码导致越来越多的MVC三层庞大错综,依赖严重,很多进行业务拆分的时候发现MC已经完全没有办法拆开了,工程量浩大,最后只有把代码写得越来越像面条,越拉越长

最近自己重写框架的时候我的View类不得不从static转换为普通类,使用new的方式实例化,因为只有这样我才能在模板中使用$this指向View类,从而在模板里面调用一些View的功能函数,如request实例$this->request()->get('user_id'),获取$_GET参数user_id,但是如果这样做我原来代码里面View::display('index.php')这样的调用方式就不行了,在PHP5.5中会有一个警告,说你使用静态方式调用非静态类,但是我又不想使用new的方式,一方面不够优雅,另一方面不够独立,如果给在Controller里面使用View就需要继承或者实例化之后赋值给Controller的一个属性,这样就依赖了,我希望Controller是独立的,在不使用View的时候(很多情况的API开发不需要View)完全都不用引入View类,而这个问题正是Laravel的Facades解决的

Facades允许使用静态方式调用非静态累,具体可以看代码的__callStatic,原理很简单,尽管这样牺牲了一些性能,但为了这个优雅性我觉得还是值得的,然后最重要的是IoC和Facades的结合,为什么Laravel能和使用大量的第三方框架的代码,完全基于其先进的IoC思想,不用怎么改动第三方代码就可以轻松的注入到IoC容器中,然后组织绑定到Laravel中,看起来像东拼西凑的,其实核心思想就是这样的,任何模块都是独立的,就好像盖楼一样,所有的配件都是独立生产的,然后组合到一起,只有这样框架的耦合才完美的解决了,因此我现在写代码都会写得特别独立,不需要用某个功能,直接删除掉相应的文件,整个框架不受任何影响,依旧顺畅执行

说了很多,其实主要是想说国外很多框架之所以火不是没有理由的,要学会从中立的角度去看待别人的思想精髓,不能从程序员简简单单的测评就一口否定,这也是开源的精髓,集思广众

巴扎黑

本人项目历程:原生PHP->CodeIgniter->Yii1->Yii2

2014年07月12日那会,Yii2处于Beta期,Yii官方也不推荐用于生产环境,同时个人也认为还不成熟。

经过一年时间发展,目前截止2015年10月15日,Yii2已经非常成熟了,而且本人目前的项目也是基于Yii2开发的,已运用到生产环境中。

具体开发、修复bug历程,可以看Github和官网

目前,部分文档并不健全,比如 Development Tools 模块,指南文档

小葫芦

swoole如何? http://www.swoole.com/

大家讲道理

Laravel 我尝试过写一个DEMO,并没有想象中那么好用,个人觉得小项目用 CI 足够,大项止还是用 Symfony2 吧!

小葫芦

我个人认为Laravel对第三方包依赖太多(特别是Symfony),给人的感觉就是对Symfony的二次开发

PHPzhong

Laravel API文档也太精简了吧。精简得让你不看源码都不知道怎么用。

刘奇

laravel5.1一个空项目,或者链接数据库,取一个表的几条记录显示出来:
用 ab -t 10 -c 10 http://127.0.0.1/laravel511/public/index.php
或 ab -n100 -c100 http://127.0.0.1/laravel511/public/index.php
得出的结果 request per time: <50

而如果换slim3 或 ci3 测试,可以达到 reququest per time : 200-300

如果不用任何框架,同样测试,则可以达到:request per time : 1300

不明白这样的情况下,还要用框架吗,项目套上框架性竟然能这么低啊。

赶脚白瞎了机器硬件啊。

Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template
About us Disclaimer Sitemap
php.cn:Public welfare online PHP training,Help PHP learners grow quickly!