Lifesign's Blog

PHP框架之我见

##选择哪个框架?

听到很多人在谈起框架的时候,大部分用的词就是哪个框架好?
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的生态圈往更好的方向发展,但是未来走成什么样,我们都不知道,只有隐藏在框架背后那些闪光点才是我们应该牢记的。