php 各种框架优缺点 及 laravel框架与thinkPHP框架的区别

一直以来，phper讨论最多的就是php各种框架的优缺点，网上的资料也是比较零散，现把几款主流的框架收集汇总一下，其中本人只是用过Yii2、Laravel、Yaf、Thinkphp这四种框架，因此大部分对各种框架的评价皆来自与网上资料，如果问题，请在评论中指出，共同进步

一、ThinkPHP

ThinkPHP(FCS)是一个轻量级的中型框架，是从Java的Struts结构移植过来的中文PHP开发框架。它使用面向对象的开发结构和MVC模式，并且模拟实现了Struts的标签库，各方面都比较人性化，熟悉J2EE的开发人员相对比较容易上手，适合php框架初学者。 ThinkPHP的宗旨是简化开发、提高效率、易于扩展，其在对数据库的支持方面已经包括MySQL、MSSQL、Sqlite、PgSQL、 Oracle，以及PDO的支持。ThinkPHP有着丰富的文档和示例，框架的兼容性较强，但是其功能有限，因此更适合用于中小项目的开发。

优点

1.借助成熟的Java思想
2.易于上手，有丰富的中文文档；学习成本低，社区活跃度高
3.框架的兼容性较强，PHP4和PHP5完全兼容、完全支持UTF8等。
4.适合用于中小项目的开发
5.从thinkphp3.2.2引入composer包管理工具

缺点

1.对Ajax的支持不是很好；
2.目录结构混乱，相比其他框架目录结构要差一点；
3.上手容易，但是深入学习较难。


二、Yii

Yii 是一个基于组件的高性能php框架，用于开发大型Web应用。Yii采用严格的OOP编写，并有着完善的库引用以及全面的教程。从 MVC，DAO/ActiveRecord，widgets，caching，等级式RBAC，Web服务，到主题化，I18N和L10N，Yii提供了 今日Web 2.0应用开发所需要的几乎一切功能。事实上，Yii是最有效率的PHP框架之一。

优点

1.纯OOP
2.用于大规模Web应用
3.模型使用方便
4.开发速度快，运行速度也快。性能优异且功能丰富
5.使用命令行工具。
6.支持composer包管理工具

缺点：

1.对Model层的指导和考虑较少
2.文档实例较少
3.英文太多
4.要求PHP技术精通，OOP编程要熟练！
5.View并不是理想view，理想中的view可能只是html代码，不会涉及PHP代码。

三、laravel

优点
1.laravel的设计思想是很先进的，非常适合应用各种开发模式TDD, DDD 和BDD
2.支持composer包管理工具
3.集合了php 比较新的特性，以及各种各样的设计模式，Ioc 容器，依赖注入、门面、契约。测试功能等。

缺点
1.基于组件式的框架，所以比较臃肿

四、CodeIgniter

优点：

1.Code Igniter推崇“简单就是美”这一原则。没有花哨的设计模式、没有华丽的对象结构，一切都是那么简单。几行代码就能开始运行，再加几 行代码就可以进行输出。可谓是“大道至简”的典范。 
2.配置简单，全部的配置使用PHP脚本来配置，执行效率高；
3.具有基本的路由功能，能够进行一定程度的路由；
4.具有初步的Layout功能，能够制作一定程度的界面外观；
5.数据库层封装的不错，具有基本的MVC功能. 
6.快速简洁，代码不多，执行性能高，
7.框架简单，容易上手，学习成本低，文档详细；
8.自带了很多简单好用的library，框架适合小型应用.

缺点：

1.本身的实现不太理想。
2.内部结构过于混乱，虽然简单易用，但缺乏扩展能力。
3.把Model层简单的理解为数据库操作. 
4.框架略显简单，只能够满足小型应用，略微不太能够满足中型应用需要.

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


五、Zend Framework

优点：

1.大量应用了PHP5中面向对象的新特征：接口、异常、抽象类、SPL等等。这些东西的应用让Zend Framework具有高度的模块化和灵活性
2.严格遵循“针对接口编程”和“单一对象职责”等原则
3.官方出品，自带了非常多的library，框架本身使用了很多设计模式来编写，架构上很优雅，执行效率中等
4.MVC设计，比较简洁
5.具有路由功能，配置文件比较强大（能够处理XML和php INI)
6.能够直观的支持除数据库操作之外的Model层（比 CodeIgniter 和 CakePHP 强），并且能够很轻易的使用Loader功能加载其他新增加的Class
7.Cache功能很强大，从前端Cache到后端Cache都支持，后端Cache支持Memcache、APC、SQLite、文件等等方式
8.数据库操作功能很强大，支持各种驱动（适配器）
9.文档很全，在国内社区很成熟

缺点：

1.MVC功能完成比较弱，View层简单实现（跟没实现一样），无法很强大的控制前端页面.
2.没有自动化脚本，创建一个应用，包括入口文件，全部必须自己手工构建，入门成本高
3.对于简单和小型的项目来说,反而因为在框架中应用了大量面向对象设计,对开发者提出了更高的要求，间接增加了项目的开发成本

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


六、CakePHP

优点：

1.最类似于RoR的框架，包括设计方式，数据库操作的Active Record方式
2.设计层面很优雅，没有自带多余的 library，所有的功能都是纯粹的框架，执行效率还不错
3.数据库层的 hasOne, hasMany功能很强大,对于复杂业务处理比较合适
4.路由功能，配置功能难度适中
5.自动构建脚手架（scaffold）很强大,适合中型应用
6.基本实现过了MVC每一层
7.具有自动操作命令行脚本功能
8.文档比较全，学习成本中等

缺点：

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

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


七、Symfony

优点：

1.完整实现了MVC三层
2.封装了所有东西，包括 $POST，$GET 数据，异常处理，调试功能，数据检测
3.包含强大的缓存功能
4.自动加载Class,能够很随意的定义各种自己的class
5.强大的语言支持
6.具有很强大的view层操作，能够零碎的包含单个多个文件
7.非常强大的配置功能，使用xml配置能够控制所有框架和程序运行行为
8.包含强大的多层级项目和应用管理：Project --> Application --> Module --> Action，能够满足一个项目下多个应用的需要，并且每层可以定义自己的类库，配置文件，layout
9.非常强大的命令行操作功能，包括建立项目、建立应用、建立模块、刷新缓存等等
10.Symfony绝对是开发大型复杂项目的首选，因为使用了Symfony，将大大节约开发成本，并且多人协作的时候，不会出现问题，在Project级别定义好基础Class以后，任何模块都能够重用，大大复用代码.

缺点：

1.最大的问题也在于使用了太多风格迥异的开源项目来组合成框架
2.由于Mojavi和Propel本身都相当复杂，因此Symfony的结构非常复杂，难以理解和学习
3. 缓存功能无法控制，每次开发调试总是缓存，需要执行 symfony cc,symfony rc来清除和重建缓存
4.效率不是很高，特别是解析模板和读取配置文件的过程，花费时间不少
5.学习成本很高，并且国内没有成熟的社区和中文文档

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


总评：
以上数款框架，各有特色,而且都是开源项目,不过框架针对的项目不一样，一般来说：

1.小型项目：CodeIngiter

2.中型项目：CakePHP、Zend Framework、Laravel、Thinkphp

3.大型重量级项目：Yii、Symfony、Laravel

以上划分也不绝对，在项目选型的时候,要充分考虑框架的可以定制性、扩展性，因为每个项目都无法确定你是否会随着需求的变化进行改变

 

--------------------------------------------------------------------------------------------------------------------------------------

主要区别:(thinkPHP更适合国人的编码习惯)

1.渲染模版方式的不同:

在Laravel框架里,使用return view()来渲染模版;

而ThinkPHP里则使用了$this->display()的方式渲染模版;

2.在Laravel框架里,由于其考虑到了跨站请求伪造, 所以如果使用form表单以post方式进行传值时,如果不再form表单中加入{{csrf_field()}}则会报出TokenMethodnotfound的语法错误;

而TP框架则需要自己手动完成防止跨站攻击的代码;

3.Laravel是一个重路由的框架(5.4),所有的功能都是由路由发起的,哪怕没有控制器方法,只要写了路由就能够访问,thinkPHP(3.2),必须要有控制器方法才能正常访问;

4.laravel具有强大的社区化扩展，（composer扩展自动加载）;

5.laravel具有强大的Blade模版引擎;

6.中间件，Laravel特点，可以实现访问前后的处理，例如请求和返回，权限认证等;

7.条件判断语句书写方式的差异:

Laravel框架里 if else判断语句和foreach语句 书写时必须以@if开头  以@endif结尾,如果没有则报语法错误,@foreach @endforeach同理;

而TP框架则和PHP语法规则使用方式一致直接ifesle语句判断和foreach循环遍历

    

Laravel里内置了大量的方法供开发者使用,在实际应用中更接近于"让对象完成一切"的开发思想,比如在后台表单验证的时候,Laravel内置了大量的验证方法,例如对用户名的验证:我们使用可以validate方法里'username'=>'required'(不能为空)|alpha_dash(必须数字字母下划线)|between:6,18(在多少位数之间);还内置了例如email;same:字段名;diff:字段名等大量的方法极大的提高了开发速度;

    加密方式 在TP框架中 我们对用户名密码进行加密时使用md5();的方式进行加密,但md5的缺点在于其可以逆向破解,而且在同等规则下同样的密码md5加密出的字符串是有可能出现相同的,这就降低其安全性;

但在Laravel框架中内置了"哈希"Hash加密单向加密方法,且同样的参数加密出的字符串是绝对不会出现相同的情况 这就提高了安全性;

    在实际开发中我们常常遇到这样的问题,就是开发地点不固定,这就造成了我们需要频繁的更改数据库配置,给开发工作造成了麻烦,TP依然没有避免这个"灾难";在laravel框架中,.env环境文件的出现解决了这个麻烦,我们只需要在不同的工作地点配置好.env文件就不必再进行配置,因为无论是git还是svn " .env是不会随着文件一起提交到服务器的";
 

-------------------------------------------------关于TDD、BDD和DDD的一些看法-------------------------------------------

在实际的项目中，我们可能随时面对各种不同的需求，它的各个方面的要素决定了我们所采用的开发模式。

比如，它的复杂度如何？所有的需求是否足够清晰？开发人员对相关的业务是否足够了解？项目的工期是否合理？种种问题，不一而足。这也决定了我们可能面对不同的需求可能需要采用不同的开发模式。下面大概说几种。

 

1. TDD

TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说我们可以从测试的角度来检验整个项目。大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。

TDD的好处自然不用多说，它能让你减少程序逻辑方面的错误，尽可能的减少项目中的bug，开始接触编程的时候我们大都有过这样的体验，可能你觉得完成得很完美，自我感觉良好，但是实际测试或者应用的时候才发现里面可能存在一堆bug，或者存在设计问题，或者更严重的逻辑问题，而TDD正好可以帮助我们尽量减少类似事件的发生。而且现在大行其道的一些模式对TDD的支持都非常不错，比如MVC和MVP等。

但是并不是所有的项目都适合TDD这种模式的，我觉得必须具备以下几个条件。

首先，项目的需求必须足够清晰，而且程序员对整个需求有足够的了解，如果这个条件不满足，那么执行的过程中难免失控。当然，要达到这个目标也是需要做一定功课的，这要求我们前期的需求分析以及HLD和LLD都要做得足够的细致和完善。

其次，取决于项目的复杂度和依赖性，对于一个业务模型及其复杂、内部模块之间的相互依赖性非常强的项目，采用TDD反而会得不尝失，这会导致程序员在拆分接口和写测试代码的时候工作量非常大。另外，由于模块之间的依赖性太强，我们在写测试代码的时候可能不采取一些桥接模式来实现，这样势必加大了程序员的工作量。

 2. BDD

BDD指的是Behavior Drive Development，也就是行为驱动开发。这里的B并非指的是Business，实际上BDD可以看作是对TDD的一种补充，当然你也可以把它看作TDD的一个分支。因为在TDD中，我们并不能完全保证根据设计所编写的测试就是用户所期望的功能。BDD将这一部分简单和自然化，用自然语言来描述，让开发、测试、BA以及客户都能在这个基础上达成一致。因为测试优先的概念并不是每个人都能接受的，可能有人觉得系统太复杂而难以测试，有人认为不存在的东西无法测试。所以，我们在这里试图转换一种观念，那便是考虑它的行为，也就是说它应该如何运行，然后抽象出能达成共识的规范。如果你用过JBehave之类的BDD框架，你将会更好的理解其中具体的流程。这里我推荐一篇具体阐述的文章。亲身体验行为驱动开发。

另外，关于TDD和BDD之间的关系，还可以参考这篇文章: 虚拟座谈会：代码测试比率、测试驱动开发及行为驱动开发

 3. DDD

DDD指的是Domain Drive Design，也就是领域驱动开发。这是一种非常好的思想，在我们刚开始学习程序，甚至刚开始学习三层架构的时候，我们曾经面临过很多疑惑，比如如何来实现我们的数据层？后来我们开始学习MVC，MVP等架构，如何设计Model层又成了我们的新问题。我们见过太多这种情况，Model变成了单纯的数据容器，也就是我们经常说的贫血模式。DDD实际上也是建立在这个基础之上，因为它关注的是Service层的设计，着重于业务的实现，因此不可避免的以贫血模式为基础而存在。但是它最大的特别是将分析和设计结合起来，不再使他们处于分裂的状态，这对于我们正确完整的实现客户的需求，以及建立一个具有业务伸缩性的模型，是有很大帮助的。