think in php framework

yak 发布于 2011/03/31 09:11
阅读 3K+
收藏 7
PHP


1  从市场定位来说,框架的定位就很模糊,小站的话,满地的cms,还有dz全套产品,基本能满足需要,从应用级别就已经包揽了很多工作,只需要做些模板美化,数据调用和显示的工作,不用费心心思的去想多表如何关联,关联完了,还要写很多业务方法. 做大站的话,提框架的人会被鄙视的,大站更多的处理前端的http协议,缓存,表现层的东西,还有安全防护的处理, 这个也可以从招聘贴看出来,小公司都要求会什么dz,ecshop,drupal,joomla二次开发经验,从来没见过sina,baidu,yahoo,tx招人要求熟练某某框架的

2 从技术实现上来说,相比java,python,ruby这种daemon机制,php是用一种简单粗暴的plugin机制,当然这样限制了一些高级的技术,比如数据库连接池,单件,如果写了100个类,不管用了多少Singleton ,请求过来,io到内存,解析,执行,返回结果,打扫干净(如果限定时间没处理完直接kill),用了apc也只不过省掉解析这一步,现场依然要打扫得干干净净,如果access.log中记录了1000次请求,java的单件只需new一次(只要应用服务器不重启),php new1000次,基本是多少请求就多少次单件,我看不出在页面级别实现单件有什么意义,本来是一种很简单高效的plugin,框架们在一个在插件实现的地方,硬生生拉出一沱来,本来处理一下请求参数,根据请求参数query数据,然后返回字符串, 而现在的框架们要用rewrite(性能损耗)重写到单入口,然后io进来框架依赖的一大堆类(这时候还没到请求,纯多出来的io),然后检测这个,检测 那个,处理路径参数,最后根据url参数 call_user_fuction或者$controller->$action 这时才进入请求(所以Rasmus Lerdorf教诲说,好的架构是Avoid front controllers), 本来一个简单的action,可能是一个query,一个update,或者简单的显示一个操作提示,用controller类来实现把所有的 action都装到一个篮子里,当然这样代码很 好看,但是当代码膨胀的时候,你发现你在需要一杯水的要求下,框架会给你提来一桶水,然后你喝完一杯水,一桶水就泼掉了,而且这样的io,在成千上万的请 求中都要执行,因为这是框架的基础,本来推门就可以出去的,非要绕场一周才推门出去,接着再io一大堆进来要实现orm的类,关于orm就不用多说了,包 话java的orm实现,orm发展这么久,如果在实际应用中是个好的方案,就不会出现这么多nosql的方案了,当然查些简单的数据,就象写 helloword一样是很方便,但helloword的程序有多少价值?有多少实际应用的业务逻辑是象查个一个用户发了多少博客这样简单?当然,框架们会说有这个好,有那个好,但是就象广告中说的那样,"好不好,看疗效",在没有用框架的年代,有phpmaidn,phpwind,phpbb,drupal,wordpress,discuz,Joomla,满地的cms就不用说了,用了框架的年代,又有什么呢?也可能是我孤陋寡闻,至少我没到看到哪个用框架开发的应用能够在大流量,高并发的环境下跑得顺溜的,在可以预见的将来,也不会有,就象盖楼一样,你的地基决定了你能盖楼的高度

3 从实际经验看来,框架最益的地方在于适合团队开发,在技术规范层面强制实现了代码风格一致(代码规范也可以完全按约定的方法来实现),但是一个团队中所有 成员都熟悉一个框架的概率有多少?,实际中经常看到的情形里,很多初级的开发者为了各自推崇的框架的争得面红耳赤,唾沫星子乱飞,有时候还能升级冲突, 在论坛,qq 群中这种情况尤为常见,毕竟很少有人有时间把流行的框架都上手玩一遍,尤其现在框架泛滥的情况下,现在阿猫阿狗都开始写框架,新框架基本成了月经贴,隔一 个月就能推出一个新的框架,但你打开代码一看,基本就是包装include+$controller->$action +db类,如果我要用nosql做sns,你发现找不到一个能适用的框架,这也从一个侧面反映了php的开发水平参差不齐,而且都比较浮燥,ruby这么 写,我也这么写,别人买盐,我也买盐,别人退盐我也退盐,没有人停下来看看到底盐到底能干什么,我到底需不需要盐,ruby用ror是因为ruby可以常 驻内存,在production模式下,写多少类,在服务器启动时已经加载到内存了,请求过来,直接dispatch,然后用yield可以实现很多好玩 的hook.

4 框架们的另一个理由是用框架可以快速开发,但只有框架们这么说,你去听听那些一线的开发或者资深php开发怎么说(这些人是一般是公司开发的主力),真实实现快速开发的是php类,比如验证,上传,图片处 理,模板,socket,缓存,如果直接有一个封装很好的类可用,比自己重新造轮子要省力很多 ,当初最经常上的就是pear站和phpclasses, 需要用到什么,直接一搜,排在前面的肯定是质量比较好的类(得益于rate机制),直接拿来用就是了,类可以做到按需加载,action中不需要就不加 载,类比框架更好的一点是,类是共容的,而框架是排他的,用了多个类可协同工作,但是很少说一个应用中有同时多个框架的,框架只能单选,而类可以多选,类 的的粒度更小一些,而且类对开发者更友好一些,可以学一些基本的封装技巧,设计模式,或者一些函数实现,但是如果用框架,如果一个功能框架中没有实现或者没有考虑到或者有bug但框架不维护了(貌似qeephp现在已经停止更新了),基本就傻眼了.

加载中
0
G.
G.

由于PHP的运行机制, 框架确实无法在运行时给系统带来多大好处, 相反, 还带来不少了性能损耗.

但是, 它能起到很好的代码规范作用. 这并不能加快多少编码速度.

不过, 当你在维护一份由多人编写的系统时,它能救你一命. 至少不会让你有杀人,或者跳楼的冲动.

0
主编
主编

drupal 没中文资料 崩溃,,

0
yak
yak

去年参加过一个开源技术的讨论会,还专门卖drupal的书呢

0
曾建凯
曾建凯

单纯以性能说,框架的性能未必差,只是你没有做足够的了解而已。

实际上,框架在于集中了编码的范围,其次才是风格统一。风格统一无论如何都需要人为的约束,就好像ruby on rails,ruby的语法,要实现一个功能,可以有多种做法,然而大家肯定需要有一个约定。所以风格是人为的。可是编码范围的限定,却是通过框架所限制的,当然,这又看是什么框架,他是不是限定了这种范围。

PHP本身是一个无拘束的语言,这是他的优点,也是他的缺点。说框架影响性能,其实是狗屁,看看wordpress、dz的产品,include多少文件,预先做了多少层的处理,回来看看,其实都没差别。

关于并发的问题,我的框架09年末经过高并发,apache ab测试的并发是185/s,而实际上可承受并发是150/s,一个请求里,session用数据库存取,请求3条SQL查询,数据库上百万级。而且是持续一周之内的24小时都存在这样的并发数。最终PHP没挂,框架没挂,是放在这台服务器前面的静态页面站点挂了(windows 2003 IIS 6)。

高并发只是一个没有实际价值的理论讨论值而已,服务器周边有各种加速优化的方案,静态化、集群、负载均衡,如果一个网站24小时内都能有150/s,那他已经火到不行了。完全有足够的空间去做性能方面的优化。

所以,你要针对框架说事,请你看足够多的代码再说吧。

0
沙逛鱼
沙逛鱼

php也是越来越臃肿,当初能被接受,一个主要原因就是简单,可如今,语法也是复杂的不得了,面向对象等等。不比学java的成本低到哪里

0
yak
yak

最终PHP没挂,框架没挂,是放在这台服务器前面的静态页面站点挂了

膜拜ing

0
yak
yak

所以,你要针对框架说事,请你看足够多的代码再说吧。

讨论的基础是一些基本的经验常识和数据,否则讨论就没有意义,如果你要证明你的论点,请拿出有说服力的论据和清晰的逻辑,我看不出谈框架跟足够多的代码有什么逻辑关系,我研究过yii,qeephp的代码,在以前的公司用zf做过两个应用,用ci做过一些简单的外包,不过这不重要, 软件测试中有一种测试叫黑盒测试,判断一个菜好不好吃对有些人来说复杂得不得了,我可以告诉一个简单有效的办法:尝一下就知道.看代码多少跟谈论框架没有必然联系,qq群,论坛里很多初学者没看过多少代码,但这并不影响他们对各种框架做测试,做评测,就算看过再多的代码,但是水平没有提高,依然是个低级码农的角色,

0
yak
yak

单纯以性能说,框架的性能未必差,只是你没有做足够的了解而已。

上面是我关于就"单纯以性能说"对框架的了解,

除了

最终PHP没挂,框架没挂,是放在这台服务器前面的静态页面站点挂了

 

能否也分享一下你关于框架性能方面"足够的了解"?

 

返回顶部
顶部