选择哪个框架？
听到很多人在谈起框架的时候,大部分用的词就是哪个框架好?
A可能说： 某某框架有一个很牛x的功能 用的太爽啦 B：哼 这个功能xx框架也有,还比他更牛x 比如bla bla bla。。
所以讨论的结果,除了听到了一个新的框架名,可能最终还是各自用各自的框架,各自扫门前雪。
我觉得选择一个框架的重要一点是由需求来决定的, 在构建项目初期，就应该根据项目规模来决定选型。这个项目主要是做什么 是博客? cms? 电商或是其他
比如你就是用来写一个小 demo 展示展示页面 拿 zend framework来写显然是不合适的。
其他方面
扩展性：
选择一个框架的时候至少对这个框架的扩展层面有一定的了解,比如缓存、数据库 看是否能在统一外部调用接口的情况下,方便扩展和切换。
可维护：
每个项目都有自己的生命周期,在开发结束之后,剩下的大部分时间可能就是在维护一个产品,这时候项目的结构和开发流程就显得比较重要 如何让新来的同事快速接手或者自己重新写扩展的时候比较方便,这也是一个因素。 像严格的mvc模式 c、m、v目录 基本都是被大家所认可的 开发起来也大致知道怎么放代码 怎么写代码。
性能问题：
很多人都在关注所谓的性能问题,但是真的从一个hello world上能比较出什么么,我写一个40行的单文件类,绝对比那些框架快,但是有啥用?
中小框架在意执行效率 大型框架在意生产效率。
很多同学把程序性能当成头等大事,但是对于大型的项目来说,往往结构 以及生产效率才是值得关注的。性能可以通过其他层面来弥补。
有一句话是这么说的：不要过早的去优化所谓性能,没达到瓶颈之前那就是过度设计。
了解框架层面以外的东西
我们大部分程序员可能一直都处在”用”一个框架的层面,不管是内部的、开源的、或者自己写的。
和上次新来的一个哥们交流 给我的感觉就是 我会用xx框架 xx框架如何如何。
我反问换个框架你会用不 给你三天时间熟悉一个新的框架 两星期做个demo可否？
他不置可否。
所以不能被框架限制住了我们的思维,除了框架本身的api,更多的要了解框架层面以外的东西。
比如http协议 比如设计模式 比如缓存方案、数据库设计、大并发的处理,这些东西都是每个框架都会面临的共有的问题。
当一个东西重复出现的时候 你就要思考这个东西他背后的机理是什么 如何改进。
就和写代码一样 我们最简单的重构就是 看到重复出现的代码 我们会把他用一个function包裹起来,或者用一个类封装起来、或者写成一个接口 这都是很好的例子。
遵循 DRY 原则 做到这个很难 但是我们要有这个意识。
看 web 开发层面 而不是 PHP 语言层面
现在的 web 开发 虽然 PHP 占了主流 但不代表是唯一。 Java、ruby、python、nodejs都占有各自的一部分天地。
我们要了解和吸收的应该是其他语言在 web 开发层面比较好的理念和解决方案,而不是局限在 PHP。
这里以依赖包管理来简单讲讲：
我们应该都有这样的意识,当我想要某个功能的时候 如果不想自己写 我们可能会去市面上找已经写好的某个类库 然后把他们用到自己的项目中。
在 PHP 层面可能只是一个单文件类,或者一个类库,封装好了想要的功能。于是我们把他集成进来了 功能跑起来了 客户很满意。 ok 解决问题。 确实,在大部分情况下这样就够了。 但是进一步思考一下,如果哪天客户对于这个扩展类的需求又变了,你是重新寻找新的类库?还是在之前的类库上增加扩展?如果要增加,该怎么加? 是不是好加? 加了之后怎么维护？也许你把他扩展了,自己用的很好,也想开源出去给别人用, 放哪？有可能你会放到 github 上,但是谁知道？ 你也不可能花太多的时间去推广你的类库。当无人问津的时候,你写的东西可能就跟杂草一样,只能慢慢腐烂成记忆。
这也就意味着我们一直在重复造着各种各样的轮子,质量还层次不齐。
看看其他语言怎么做的
ruby有 gem nodejs有npm python有pip。。
PHP 有什么？
老掉牙的 pear？ no！Composer 的出现就是为了解决依赖包管理。相当于上面其他的语言的依赖管理器
当我们想要一个功能的时候 可以直接去搜索关键字 找到需要的功能,
写一个 composer.json 文件把需要的依赖写进去 然后执行 composer install
ok 这样你需要的依赖就集成到你的项目中了
好处是什么呢？
- 对于自己的项目版本控制来说,维护的代码可以更集中在业务层,因为各个vendor是不需要提交到版本控制的,我们只维护一个composer.json即可。
- 每一个vendor的维护者,只需要维护自己的这个vendor即可,关注于这个vendor可提供什么功能,这样有利于vendor功能的完善。
- 每一个vendor遵循单一职责,只做好一件事,又具备良好的扩展性和维护性,同时又有一个统一的渠道去被人所知,更加会促进开发者的持续开发 达到良性循环。
以上就是通过借鉴其他语言的良好设计 来改善自身生态圈的一个很好的例子。
框架的未来
纵观现在 PHP 所谓的框架,类型大致有以下几种,严格的mvc框架,微框架,简单路由,全栈框架,组件式框架。
随着5.3版本以上带来的新特性,很多现代的框架 都抛弃兼容5.2以下,开始采用5.3以上的新特性来开发框架,使得代码更加优雅,功能也更加强大。
特别是ioc容器和闭包的结合使用 现在很多框架都采用这种模式 而 Symfony 和 Laravel 走在时代的前沿 更多的带来了组件式的思想 把框架涉及到的每一个层面设计成单独的组件 进一步降低了耦合性 同时通过 ioc 这个 glue 良好的把各个组件连接了起来,架构精巧,代码优雅。
我想 Symfony 的这种设计应该会带动 PHP 的生态圈往更好的方向发展,但是未来走成什么样,我们都不知道,只有隐藏在框架背后那些闪光点才是我们应该牢记的。
