听说laravel挺火，就用看了一下，没有深入去看，算是只看完快速入门，看了以后有点失去兴趣了，特来知乎请教一下。如果这东西都是用composer的方式调入各种第三方的包来完成任务，那么灵活性是不是太低了一点，虽然没有重复造轮子，但是最后大家弄出来都是一样的轮子，还有安全性好保证么，听说效率也不高啊。如果不使用第三方包的情况下，能加快多少开发速度呢？会不会反倒不如其他的框架？
追加：有些回答觉得我对laravel不够深入所以评价不客观，ok，我想这也是有可能的，虽然第一感官不好了，但为了不武断作出结论，我决定继续深入下去，如果不好，到时候再回来反驳你们，哼哼，=P。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
回复内容：
子之武城，闻弦歌之声。夫子莞尔而笑，曰：「割鸡焉用牛刀」。 --- 《论语》我们学习一个框架，不是因为他简单易学，而是因为他高效强大。
Laravel 框架的出现，将 PHP 的后端开发带入了一个新的高度，其中的 composer 和 PHP-FIG 等，标志着 PHP 已经不再仅仅是“前端语言”、“展示层语言”了。
PHP 的特点就是易于入门，而且 PHP 是一个语法大杂碎，汇集了 C Perl 等等，当年我学了半天时间，就可以拿来做网站了。
对于框架，大部分 PHPer 会首选 ThinkPHP 或者 CI。因为这几个框架的门槛和 PHP 的门槛很对口。如果像 Java 那样，学习半年才能做开发，大部分的 PHPer 是接受不了的。如果一个框架（比如 SSH）需要学习半个月才能上手，PHPer 们也接受不了，于是 TP 和 CI 框架大行其道。（PHP 界和 SSH 框架媲美的 ZF 也被 PHPer 鄙视为大而无用，处处透漏这 Java 的臭毛病）
随着 Laravel 的出现，我毫不犹豫的从 CI 转入了 Laravel 阵营。
如果你仅仅是为客户写一个网站，那么即使原生的 PHP 也可以应付，如果想再提高点儿效率，可以选用 TP 或者 CI。
但是，如果你是为公司或者自己开发一个项目，这个项目准备运营五年以上，那么 CI 的弊端就凸现了。五年间，CI 估计都已经升级了 N 版了，PHP 也升级了 N 版了。你升级吗？
项目是在本地开发调试完成，当上线后遇到问题了，我们如何查找，如何跟踪呢？最通常的办法就是 log。现在几乎每个框架都有 log 功能，但是 Laravel 的又一强大之处就是他的 log 遵循 PHP-FIG，也就是以后你可以随意更换 log 的实现类以提高性能。这就好比我们的 PC，它上面都有 USB 接口，这样我们就可以任意更换 USB 设备，比如 USB 鼠标，USB 键盘，USB 硬盘等。而 Laravel 依据 PHP-FIG 标准提供日志接口，我们只需要更换实现。
那么现在问题来了，
如果这东西都是用composer的方式调入各种第三方的包来完成任务，那么灵活性是不是太低了一点使用 composer 不是为了调入，而是为了管理，管理包，以及各种包的版本。这样就解决了各种包的兼容问题。而在 composer 出现之前，PHP 依然没有有效的方法解决这些问题。如果我们需要一个 Excel 的导入导出功能时，就去搜索 PHP 的 Excel 库，大部分情况是去官网下载最新的稳定版本。如果出现问题了，就去谷歌或者百度搜索，“我去~原来是版本问题，这个库使用了匿名函数，PHP 5.3 不支持，哎，只能下载以前的版本了~~”。
Composer 将工程化的思想带入了 PHP。
如果不使用第三方包的情况下，能加快多少开发速度呢？
如果仅仅是开发速度，Laravel 无疑是低效的，笨重的。这显然和“世界上最好的语言”不相搭配。但是如果你开发过大中型项目就会发现，编码（Coding）其实在整个项目阶段，连三分之一都占不到。再退一万步讲，开发周期也许是3个月，但是整个项目的生命周期确实3年啊。
如果你的行程是10公里，那么无疑开车是最快的，如果坐飞机的，估计还没有来得及起飞呢。如果行程是100米呢，走路无疑是最快的。
再说说另一个被 PHPer 忽略的问题，那就是单元测试。同样是 MVC 框架，但是 PHPer 很多是为了 MVC 而 MVC，为了设计模式而设计模式。知其然而不知其所以然。如果问一个 PHPer 为什么使用 MVC，为什么使用模式，估计大部分都答不出来。
今天下午还在 sf 看到一个类似的提问，大意是 ThinkPHP 的模型有什么用，这些代码完全可以写在控制器里面，这样速度还快。诚然，大部分 PHPer 不知道为什么要分层架构，即使使用了框架。
谈到分层，任何一个 java 框架都可以甩 PHP 几条街。（PS：从我的名字可以看出，我是java粉，但我也坚信 PHP 是世界上最好的语言）
现在有一个控制器，处理转账。在这个流程中，需要表单验证、控制器处理业务逻辑、持久化（存储到数据库）、渲染视图，还有一些安全处理、日志功能等。
在传统的 PHP 开发过程中，都是：编码，运行，调试改错，直到运行成功，然后打开浏览器，输入数据，点击执行，看结果，如果正确，再次输入数据，如果错误，修改，调试，再打开浏览器，重复，重复，知道自己满意为止。
我们也可以使用 PHPUnit，我们把转账功能写到一个（几个）单独的类里面，测试转账的核心功能。但是我们要想测试控制器，模型，则还需要一些黑魔法。如果在 SSH 中，就 So Easy 了，任何一个模块都可以单独拿出来进行单元测试。因为任何一个模块，都可以脱离 SSH 框架而单独运行。
在 SSH 中，我们可以把控制器拿出来，放到 JUnit 中测试控制器的功能。我们也可以把路由器模块拿出来，测试 URL 路由是否正确。等等。而在 PHP 的 CI 或者 TP 框架中，控制器不可能单独拿出来进行测试。
而 Laravel 对于 PHP 的工程化的另一个贡献就是——可测试性。 额。。。额。。。额。。。
PHP好不容易有了composer，你居然说这货没用？框架的更多目的是为了项目的可持续性，而不是能有多快的去开发一个项目。。
在这个什么都要迭代更新的年代，没有可持续的架构，就是废的。
你的系统如果有上百个功能，每个功能之间还有一定的依赖，除了包管理，还有什么好的方式，让几百个人的团队来有序开发？ 强烈推荐学习laravel，你会发现在学习过程中，你会学习到框架之外的更多知识
1.如何翻墙，因为composer的安装和使用在墙内的速度是令人发指的
2.如何翻译，因为laravel的文档大部分是英文的，比如laravel5.1是6月发布的，直到今天10月19日，完全汉化的文档还是没有。
3.如何撕逼，你要对面用TP的人的不理解，用Yaf的人的鄙视，用Yii的人的试探的目光
4.如何运维，项目上线后，面对性能低下的问题你需要redis memcache opcache php7 hhvm 等等等优化性能的方案
以上！ 首先，我个人挺喜欢laravel的。但是，我觉得没必要神话 laravel。
慢慢更……嗯。
/**********************************************************************************/
composer
只是为了方便你不用重复造轮子，其本身其实和laravel 一点儿关系也没有。
laravel只是可以用 composer 而已。 没有 laravel 你也可以用 composer ，
比如 CI3.0就支持 composer , 甚至你不用框架 也可以用 composer 。
composer的特性 和 laravel的特性 没关系……
composer 和 laravel 并不会 妨碍 你的项目代码的 自由度。
难道，当核心业务、核心数据相关的组件出现BUG的时候，
你还非要等 composer 更新版本以后 才能修正BUG吗？
当然不是的……
难道 laravel里，你就不能写 include 来引入文件， new一个对象了吗？
当然也不是的……
框架的存在，并没有缩小你写代码的自由度。
而只是提供给你了一个规范：
按照这个规范写，就可以享受这个规范带来的好处，
而自然也必然的会受到规范的约束，承受规范的坏处。
/**********************************************************************************/
重复造轮子这个事情，并不是完全无意义的
——哪怕是在工作项目中。
很多时候，可以找到的轮子是不合用的，
这种情况下就必然的需要改造轮子，乃至重做轮子。
这是很正常的事情，没必要惧怕重复造轮子。
当然、一定要评估使用旧轮子、改造旧轮子、重做新轮子之间的利弊，
权衡利弊之后再做出决定。
/************************************************************************************/
像 @justjavac 说的 LARAVEL的单元测试概念，确实是很好的。
这个确实是LARAVEL非常吸引人的地方！！！
不过如果说因为laravel支持 PHP-FIG 或者 JUnit ，我们就要支持它。
确实还是要针对不同的项目来看的……
选择自己的项目合适的框架，比起死忠一个框架 更有意义。
至于大项目……
现在存在多少 持续5年以上，单一系统维护人员超过100人的PHP项目 ？
我想并不是很多吧？
我接触到的单一系统很大的项目非常少见，
更多的还是N个小型的子系统共存的项目。
而这样的项目 如果刨除单元测试等优势……
LARAVEL有多少优势吗？感觉并不是太明显……
[当然，也可能是我没有接触过足够多的“大中型项目”的原因^_^]
/*****************************************************************************************/
LARAVEL 和 CI 给我的感觉：
CI3.0 像一个工具箱。我可以很方便的从中找出需要的工具，进行使用。通过工具箱里的工具，我也可以加工出很多方便的小工具来用。
LARAVEL 像一个车床。车床可以制造的工具和制造工具的速度，并非是工具箱可以比拟的。但是想要车床制造出工具箱里的工具来，需要下的力气也不是工具箱可以比拟的。 感觉你的需求和能力与Laravel提供的价值并不在一个位面上 Laravel的设计思想是很先进的，非常适合应用各种开发模式TDD, DDD和BDD，作为一个框架，它为你准备好了一切~~composer简直就是个php的未来，没有composer，PHP肯定要走向没落~~
对于新手来说，上手度不是很高，特别是新推出的Laravel 5， 但是学习价值非常高~~你想知道php行业里面的最新编程思维，学Laravel吧LaraBase——全栈工程师之家 其实很多事情并不复杂，怕的是复杂的理论内容。很多东西一旦想通也就那么回事儿。很多人觉得 laravel 这不好那不好、这里难哪里难，我只能说，laravel 的确不是一流和优秀的框架。laravel最大的特点和优秀之处就是集合了php比较新的特性，以及各种各样的设计模式，Ioc容器，依赖注入，等等。因此laravel是一个适合学习的框架，他和其他的框架思想有着极大的不同，这也要求你非常熟练php，基础扎实。如果你觉得laravel很困难 那么原因只有一个 你php基础不够好。
另外，善于利用命名空间和面向对象的诸多特性，去追寻一些东西，你会发现，原来这一切这么容易。 任何事物存在都有其存在的理由，不能一棒子打死，应该取其长 补其短 看了路由和orm部分，和前端backbone之类的结合应该很契合，还是很不错的，另外composer是个很好东西，关于效率问题，web程序的运行效率从来就不在框架，而在数据库，框架那一点点消耗根本不会是什么负担。
补充一下，之前说框架的消耗忽略不计也是不完全正确的，有个奇葩的，从前用drupal二次开发的时候一个简单的列表页面竟然单线程消耗20多M内存，原因就是drupal本身的配置太复杂了（不是我的配置复杂，而是系统本身复杂），为了内容配置的最大自由度，什么变量都往页面里塞。去stackoverflow上问了，得到的回答是drupal里这是正常的。。drupal总的来说也是一个框架，只不过这个框架带着一个cms系统而已，当然这样的系统对外是必须一系列优化才能用的。。
laravel框架还是蛮不错的，可以说非常全面，配合phpstorm开发还是很开心的。。
分享两套教学视频，自己从http://laracast.com上一个一个拖下来的，无字幕。。
laravel-whats-new 链接: 百度云 请输入提取密码 密码: 6cwy
laravel-fundamentals 链接: 百度云 请输入提取密码 密码: aw2h
还有一个phpstorm使用经验的分享，如果还用sublime甚至zde的朋友尽快换phpstorm吧，可以说sublime的功能它都有，但还有一些高级ide才有的功能，另外即使是vim的用户也应该尝试一下，phpstorm有插件也可以模拟vim的操作，并享受其他好处。
how-to-be-awesome-in-phpstorm 链接: 百度云 请输入提取密码 密码: hgga 我观察到一个现象：通常觉得Laravel难学且无用的开发者中，只会PHP一门语言，或者说，没有静态编译型语言（如C/C++/Java/Go等）使用经验的开发者占绝大多数。
