Rumah  >  Soal Jawab  >  teks badan

php框架 - Laravel vs CakePHP vs CodeIgniter 的看法(性能,开发效率,负债能力)

最近打算用做一个比较中型的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中文网2719 hari yang lalu1663

membalas semua(17)saya akan balas

  • PHP中文网

    PHP中文网2017-04-10 15:00:27

    CakePHP没用过不予置评。

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

    详解

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

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

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


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

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

    balas
    0
  • 大家讲道理

    大家讲道理2017-04-10 15:00:27

    你的分析很多都是错的.

    (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的时代了, 不是么?

    balas
    0
  • 高洛峰

    高洛峰2017-04-10 15:00:27

    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

    balas
    0
  • 大家讲道理

    大家讲道理2017-04-10 15:00:27

    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中,看起来像东拼西凑的,其实核心思想就是这样的,任何模块都是独立的,就好像盖楼一样,所有的配件都是独立生产的,然后组合到一起,只有这样框架的耦合才完美的解决了,因此我现在写代码都会写得特别独立,不需要用某个功能,直接删除掉相应的文件,整个框架不受任何影响,依旧顺畅执行

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

    balas
    0
  • 巴扎黑

    巴扎黑2017-04-10 15:00:27

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

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

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

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

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

    balas
    0
  • 高洛峰

    高洛峰2017-04-10 15:00:27

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

    balas
    0
  • 大家讲道理

    大家讲道理2017-04-10 15:00:27

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

    balas
    0
  • 高洛峰

    高洛峰2017-04-10 15:00:27

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

    balas
    0
  • PHPz

    PHPz2017-04-10 15:00:27

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

    balas
    0
  • 怪我咯

    怪我咯2017-04-10 15:00:27

    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

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

    赶脚白瞎了机器硬件啊。

    balas
    0
  • Batalbalas