最近打算用做一个比较中型的PHP应用,想到用比应用广泛的MVC框架。
要求
<code>1.支持命名空间 2.不支持PHP4 3.架构、性能更重要 4.长期稳定,而不是很快就会被淘汰或者解散的框架 </code>
Yii2、symfony2都太庞大,不适合。考虑到了Laravel CakePHP Kohana CI。
先说一下自己对这三款框架的看法
<code>1) CI 2.x 官网一种放弃状态 CI框架太轻巧,很多东西都要自己做,非常陈旧 CI框架在IDE中无法进行代码跟踪,点击类名无法跳转过去 2) CakePHP 2.x 为什么非得向下兼容PHP4?弄得非得用一个蹩脚的App::use()来替代namespace! 为了兼容PHP4弄得整个架构乱七八糟 如果CakePHP放弃对PHP4的兼容,应该会有更多的人使用 3) Laravel 不支持php4,支持命名空间 网上非常多的好评,仔细看每个评测文章都是复制粘贴的感觉很枪手。 </code>
网上包括segmentfault上都有对框架的比较,但基本上是都是摘抄的转载的,而不是自己使用过后的真实体会,期待有使用过后的真实体会,而不是复制粘贴网上人云亦云的测评。
<code>今天使用Laravel,发现文档不是官方宣传的那样丰富,而是少非常不清晰。 Route的所有方法有那些,根本就找不到这些说明。官方的文档只是几个简单的例子,根本就不详尽。 </code>
2015-6-16 补充:
再次回到这个问题,我已经一路使用了CodeIgniter、ThinkPHP 再到Yii2,开发了一些完整的项目。现在发觉 PHP 的 MVC 模式确实难以满足需求,到后来的 component,现在再到laravel的思路,难以理解,总是一直感觉在追赶,特别疲惫。
其实一开始,我走过太多的弯路,很多年以前,对于OOP都有着强烈的排斥和极端的抵触,原因就是使用了class 类会导致程序运行非常慢,究其根本是我使用的运行环境实在是太烂了,虚拟主机都不如,而且还是win。到后来MVC模式,加载的文件数目几乎是无法比拟。后来开始使用MVC框架,普通的主机已经完全无法支撑,绝大部分虚拟主机大部分都是win服务器、而且PHP最多最多PHP5.3就不错了,还有很大一批居然还在PHP5.0(虚拟主机就是只提供一个FTP用户名密码的那种)。
走过太多的弯路,一直以来总是被硬件条件、运行环境束缚思维。
回复内容:
最近打算用做一个比较中型的PHP应用,想到用比应用广泛的MVC框架。
要求
<code>1.支持命名空间 2.不支持PHP4 3.架构、性能更重要 4.长期稳定,而不是很快就会被淘汰或者解散的框架 </code>
Yii2、symfony2都太庞大,不适合。考虑到了Laravel CakePHP Kohana CI。
先说一下自己对这三款框架的看法
<code>1) CI 2.x 官网一种放弃状态 CI框架太轻巧,很多东西都要自己做,非常陈旧 CI框架在IDE中无法进行代码跟踪,点击类名无法跳转过去 2) CakePHP 2.x 为什么非得向下兼容PHP4?弄得非得用一个蹩脚的App::use()来替代namespace! 为了兼容PHP4弄得整个架构乱七八糟 如果CakePHP放弃对PHP4的兼容,应该会有更多的人使用 3) Laravel 不支持php4,支持命名空间 网上非常多的好评,仔细看每个评测文章都是复制粘贴的感觉很枪手。 </code>
网上包括segmentfault上都有对框架的比较,但基本上是都是摘抄的转载的,而不是自己使用过后的真实体会,期待有使用过后的真实体会,而不是复制粘贴网上人云亦云的测评。
<code>今天使用Laravel,发现文档不是官方宣传的那样丰富,而是少非常不清晰。 Route的所有方法有那些,根本就找不到这些说明。官方的文档只是几个简单的例子,根本就不详尽。 </code>
2015-6-16 补充:
再次回到这个问题,我已经一路使用了CodeIgniter、ThinkPHP 再到Yii2,开发了一些完整的项目。现在发觉 PHP 的 MVC 模式确实难以满足需求,到后来的 component,现在再到laravel的思路,难以理解,总是一直感觉在追赶,特别疲惫。
其实一开始,我走过太多的弯路,很多年以前,对于OOP都有着强烈的排斥和极端的抵触,原因就是使用了class 类会导致程序运行非常慢,究其根本是我使用的运行环境实在是太烂了,虚拟主机都不如,而且还是win。到后来MVC模式,加载的文件数目几乎是无法比拟。后来开始使用MVC框架,普通的主机已经完全无法支撑,绝大部分虚拟主机大部分都是win服务器、而且PHP最多最多PHP5.3就不错了,还有很大一批居然还在PHP5.0(虚拟主机就是只提供一个FTP用户名密码的那种)。
走过太多的弯路,一直以来总是被硬件条件、运行环境束缚思维。
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 吧!
我目前觉得yaf+composer挺爽
正在学laravel,比thinkphp和zend framework 2 都爽,光看路由就觉得优雅非凡。
CI 是PHP5.2和5.3时代的框架.
Lavarel 是PHP5.4时代的框架, 文档不全你是指L3还是L4? 而且大部分文档都可以在官方论坛里面帖子找到, 文档就是普通的索引,没有太多例子很正常, 哪个开源项目不是这样. L4 文档还算好的了.
当然中文文档肯定是跟不上了.
用过larave,除了他代码写得十分美好,接口设计得十分漂亮之外,router的性能十分差!
这么多框架~一个都没用过。thinkPhp体验过,yii也体验过,具体如何,我也不知道
我个人认为Laravel对第三方包依赖太多(特别是Symfony),给人的感觉就是对Symfony的二次开发
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:
而如果换slim3 或 ci3 测试,可以达到 reququest per time : 200-300
如果不用任何框架,同样测试,则可以达到:request per time : 1300
不明白这样的情况下,还要用框架吗,项目套上框架性竟然能这么低啊。
赶脚白瞎了机器硬件啊。
CakePhP,比较稳定,
为什么不用ThinkPHP呢

phpsessionstrackuserdataacrossmultiplepagerequestsususingauniqueIdStoredInAcookie.here'showtomanagetheMeftically : 1) STARTASESSIONSTART_START () andSTAREDATAIN $ _SESSION.2) RegenerATERATESSESSIDIDAFTERLOGINWITHSESSION_RATERATERATES (True) TopreventSES

PHP에서 세션 데이터를 통한 반복은 다음 단계를 통해 달성 할 수 있습니다. 1. Session_start ()를 사용하여 세션을 시작하십시오. 2. $ _session 배열의 모든 키 값 쌍을 통해 Foreach 루프를 통과합니다. 3. 복잡한 데이터 구조를 처리 할 때 is_array () 또는 is_object () 함수를 사용하고 print_r ()를 사용하여 자세한 정보를 출력하십시오. 4. Traversal을 최적화 할 때 페이징을 사용하여 한 번에 많은 양의 데이터를 처리하지 않도록 할 수 있습니다. 이를 통해 실제 프로젝트에서 PHP 세션 데이터를보다 효율적으로 관리하고 사용하는 데 도움이됩니다.

이 세션은 서버 측 상태 관리 메커니즘을 통해 사용자 인증을 인식합니다. 1) 세션 생성 및 고유 ID의 세션 생성, 2) ID는 쿠키를 통해 전달됩니다. 3) ID를 통해 서버 저장 및 세션 데이터에 액세스합니다. 4) 사용자 인증 및 상태 관리가 실현되어 응용 프로그램 보안 및 사용자 경험이 향상됩니다.

tostoreauser'snameinaphpsession, startSessionstart_start (), wathsignthenameto $ _session [ 'username']. 1) useSentess_start () toinitializethesession.2) assimeuser'snameto $ _session [ 'username']

phpsession 실패 이유에는 구성 오류, 쿠키 문제 및 세션 만료가 포함됩니다. 1. 구성 오류 : 올바른 세션을 확인하고 설정합니다. 2. 쿠키 문제 : 쿠키가 올바르게 설정되어 있는지 확인하십시오. 3. 세션 만료 : 세션 시간을 연장하기 위해 세션을 조정합니다 .GC_MAXLIFETIME 값을 조정하십시오.

PHP에서 세션 문제를 디버그하는 방법 : 1. 세션이 올바르게 시작되었는지 확인하십시오. 2. 세션 ID의 전달을 확인하십시오. 3. 세션 데이터의 저장 및 읽기를 확인하십시오. 4. 서버 구성을 확인하십시오. 세션 ID 및 데이터를 출력, 세션 파일 컨텐츠보기 등을 통해 세션 관련 문제를 효과적으로 진단하고 해결할 수 있습니다.

Session_Start ()로 여러 통화를하면 경고 메시지와 가능한 데이터 덮어 쓰기가 발생합니다. 1) PHP는 세션이 시작되었다는 경고를 발행합니다. 2) 세션 데이터의 예상치 못한 덮어 쓰기를 유발할 수 있습니다. 3) Session_status ()를 사용하여 반복 통화를 피하기 위해 세션 상태를 확인하십시오.

SESSION.GC_MAXLIFETIME 및 SESSION.COOKIE_LIFETIME을 설정하여 PHP에서 세션 수명을 구성 할 수 있습니다. 1) SESSION.GC_MAXLIFETIME 서버 측 세션 데이터의 생존 시간을 제어합니다. 2) 세션 .Cookie_Lifetime 클라이언트 쿠키의 수명주기를 제어합니다. 0으로 설정하면 브라우저가 닫히면 쿠키가 만료됩니다.


핫 AI 도구

Undresser.AI Undress
사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover
사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool
무료로 이미지를 벗다

Clothoff.io
AI 옷 제거제

Video Face Swap
완전히 무료인 AI 얼굴 교환 도구를 사용하여 모든 비디오의 얼굴을 쉽게 바꾸세요!

인기 기사

뜨거운 도구

MinGW - Windows용 미니멀리스트 GNU
이 프로젝트는 osdn.net/projects/mingw로 마이그레이션되는 중입니다. 계속해서 그곳에서 우리를 팔로우할 수 있습니다. MinGW: GCC(GNU Compiler Collection)의 기본 Windows 포트로, 기본 Windows 애플리케이션을 구축하기 위한 무료 배포 가능 가져오기 라이브러리 및 헤더 파일로 C99 기능을 지원하는 MSVC 런타임에 대한 확장이 포함되어 있습니다. 모든 MinGW 소프트웨어는 64비트 Windows 플랫폼에서 실행될 수 있습니다.

Atom Editor Mac 버전 다운로드
가장 인기 있는 오픈 소스 편집기

VSCode Windows 64비트 다운로드
Microsoft에서 출시한 강력한 무료 IDE 편집기

SublimeText3 Linux 새 버전
SublimeText3 Linux 최신 버전

DVWA
DVWA(Damn Vulnerable Web App)는 매우 취약한 PHP/MySQL 웹 애플리케이션입니다. 주요 목표는 보안 전문가가 법적 환경에서 자신의 기술과 도구를 테스트하고, 웹 개발자가 웹 응용 프로그램 보안 프로세스를 더 잘 이해할 수 있도록 돕고, 교사/학생이 교실 환경 웹 응용 프로그램에서 가르치고 배울 수 있도록 돕는 것입니다. 보안. DVWA의 목표는 다양한 난이도의 간단하고 간단한 인터페이스를 통해 가장 일반적인 웹 취약점 중 일부를 연습하는 것입니다. 이 소프트웨어는
