Maison >développement back-end >tutoriel php >PHP框架与Ruby/Python框架有啥不同_PHP教程
PHP:每次HTTP请求过来以后,初始化全部资源(例如创建数据库链接、加载系统类库,创建缓存等等),处理完毕,释放全部资源。
Python/Ruby:初次启动的时候初始化资源,随后的请求就不必再次初始化资源了。
PHP和Python/Ruby之间机制的区别就是:
总之,PHP和Ruby的差异还是很大的,不适合放在一起比较,其实应该比较的是Ruby和Python才对。
所以我觉得Rails这种框架性做法被PHP跟风以后,其实是把PHP带上了邪路,所以不如说是Rails在误导PHP的发展。顺便多说一句:DHH在编写basecamp之前,一直是用PHP的,并且自己还写了一个PHP的快速开发框架,他改用ruby以后,把当初自己写的PHP框架也移植过来了,这个框架实际上是Rails最初的原型。那么为什么DHH当初不直接基于PHP做Rails呢?非要改用ruby以后,才发表rails呢?你看看PHP这种运行机制就知道了,PHP做复杂的web开发框架并不是一条光明的道路。
是否选择PHP,是否选择PHP Framework, 完全应该以是否满足你的应用为指标: 事先确定框架的性能指标是否满足你的应用,测试的时候你可能要开关各种缓存技术,而且可能要模拟出你的应用设计构架,然后决定适度、适当采用框架。有人习惯对于脱离应用比较哪个语言或者框架好和坏,我觉得这让事情往往陷入僵局。没有面对的问题、就无从说起问题的解决方案。技术方案都是面对某个应用的开发。不是吗?
PHP之父Rasmus本人也明确表态他不喜欢 PHP framework. (Rasmus: "I don't like frameworks. PHP frameworks are ridiculous slow".)这是Rasmus在一次演讲中提到的:Simple is Hard。
以PHP这种"每次请求作为一个完整的生命周期"的语言来说,本身就是追求简单、反框架的。大型PHP互联网应用会在后台用Java/C++写中间件来完成复杂的业务逻辑处理。非要把PHP做成框架,并不是PHP本来应该承担的责任。(其间提到了Drupal,但其都被大家定位为产品而非框架,这里就不再累述。)
站在产品的层面来看,Python的CMS plone是最优秀的,功能非常强大,二次开发很容易,又没有drupal的性能问题。上海润普就用plone开发了好几个商业项目了,其中包括像上航的一些系统。
但问题是:即便在Python社区里面,高度产品化的zope/plone现在也渐渐不再是主流了,主流技术跑到了django那里去了。所以drupal这种反PHP理念的东西能有多大前途,我觉得很难说。
框架设计要注意开发成本,集成是好事情,但是集成过多造成的资源浪费和开发不便是一些框架在发展过程中甚至是导致极致死的原因,将框架简单化配以插件化的开发方式才是真正的框架产品化。简单之美才是美,但很多框架设计者也意识到,想把框架做简单真的是很难的事情。