为什么PHP令人不爽(对于大型系统)

Posted by ShiningRay on April 3rd, 2006

Edwin Martin <edwin@bitstorm.org>.

翻译:ShiningRay @ Nirvana Studio

我在过去的四年里一直致力于PHP应用的开发。PHP确实十分容易编写。但是PHP也有一些十分严重的缺陷。

下面我会给出我的理由,为什么PHP不适合于比小型业余网站更大的网站。

1. 对递归的不良支持
递归是一种函数调用自身的机制。这是一种强大的特性可以把某些复杂的东西变得很简单。有一个使用递归的例子是快速排序(quicksort)。不幸的是,PHP并不擅长递归。Zeev,一个PHP开发人员,说道:“PHP 4.0(Zend)对密集数据使用了栈方式,而不是使用堆方式。也就是说它能容忍的递归函数的数量限制和其他语言比起来明显少。”见bug 1901。这是一个很不好的借口。每一个编程语言都应该提供良好的递归支持。

2. 许多PHP模块都不是线程安全的
在几年前,Apache发布了Web服务器的2.0版。这个版本支持多线程模式,在这个模式下,软件一个一部分可以同时运行多个。PHP的发明者说PHP的核心是线程安全的,但是非核心模块不一定是。但是十次有九次,你想要在PHP脚本中使用这种模块,但这又使你的脚本不能合适Apache的多线程模式。这也是为什么PHP小组不推荐在Apache 2 的多线程模式下运行PHP。不良的多线程模式支持使PHP常被认为是Apache 2依然不流行的原因之一。

请阅读这篇讨论: Slashdot: Sites Rejecting Apache 2?.

3. PHP 由于商业原因而不健全
通过使用缓存,PHP的性能可以陡增500%[见基准测试]。那么为什么缓存没有被构建在PHP中呢?因为Zend——PHP的制造者,它在销售自己的Zend Accelerator,所以当然,他们不想抛弃自己的商业产品这块肥肉。

但是有另一个可选择的: APC. (Zend后来推出Zend Optimizer,免费的加速器——译者)

4. 没有命名空间
设想某个人制作了一个PHP模块用来阅读文件。模块中一个函数叫做read。然后另一个人的模块可以读取网页的,同样包含一个函数read。然后我们就无法同时使用这两个模块了,因为PHP不知道你要用哪个函数。

但是有一个很简单的解决方法,那就是命名空间。曾经有人建议PHP5加入这个特性,但不幸得是他没有这么做。现在,没有命名空间,每个函数都必须加上模块名作为前缀,来避免名称冲突。这导致了函数名恐怖得长,例如xsl_xsltprocessor_transform_to_xml让代码难于书写和理解。

5. 不标准的日期格式字符
很多程序员对 日期格式字符 都很熟悉,它是从UNIX和C语言中来的。其他一些编程语言采用了这个标准,但是很奇怪的,PHP有它自己的一套完全不兼容的日期格式字符。在C中,“%j”表示一年中的当天,在PHP中他表示一个月中的当天。然而使事情更混乱的是:Smarty (一个很流行的PHP模版引擎)的 strftime 函数和 date_format 函数,却使用了C/UNIX的格式化字符。

6. 混乱的许可证
你也许认为PHP是免费的,所有的在手册中提到的PHP模块也是免费的。错了!例如,如果你想在PHP中生成PDF文件,你会在手册中发现两个模块:PDF 和 ClibPDF。但是这两个都是有商业许可证的。所以,你所使用的每个模块,你都要确保你同意他的许可证。

7. 不一致的函数命名规则
有些函数名称是有多个单词组成的。一般有三种单词组合的习惯:

直接拼接:getnumberoffiles
用下划线分开:get_number_of_files
骆驼法则:getNumberOfFiles
大部分语言选择其中一中。但是PHP都用到了。

例如,你想要把一些特殊字符转换成HTML实体,你会使用函数htmlentities (直接拼接单词)。如果你要使用相反的功能,你要用到它的小弟弟html_entity_decode。由于某些特殊的原因,这个函数名是由下划线分隔单词。怎么能这样呢?你知道有一个函数叫strpad。或者他是str_pad?每次你都要查看一下到底这个符号是什么或者直接等他出现一个错误。函数是不分大小写的,所以对于PHP来说rawurldecode 和RawUrlDecode之间没有什么区别。这也很糟糕,因为两个都使用到了同时他们看上去还不一样,混淆了阅读者。

8. 魔法引用的地狱
魔法引用(Magic quote)可以保护PHP脚本免受SQL注入攻击。这很好。但是出于某些原因,你可以在php.ini中关闭这个配置。所以你如果要写出一个有弹性的脚本,你总要检查魔法引用是开启还是关闭。这样一个“特性”应该让编程更简单,而事实上变得更复杂了。

9. 缺少标准框架
一个成长中的网站没有一个整体框架,最终会变成维护的噩梦。一个框架可以让很多工作变得简单。现在最流行的框架模型时MVC-模型,在其中表现层、业务逻辑和数据库访问都分离开了。

很多PHP网站不使用MVC-模型。他们甚至没有一个框架。甚至现在有一些PHP框架同时你都可以自己写一个,关于PHP的文章和手册没有提高框架的一个字。同时JSP-开发人员使用像Struts的框架、ASP开发人员使用.Net,看起来好像这些概念都广泛被PHP开发人员所了解。这就说明了PHP实际上到底是多专业。

总结
 
什么问题?

对于非常小的项目,它可以是一个十分符合人意的编程语言。但是对于较大的和更为复杂的项目,PHP就显出他的薄弱了。当你不断地摸索之后,你会发现我提到的某些问题的解决方案。所以,当解决方案已知之后,为什么不能修正他呢?另外为什么这些修补不在手册中提到呢?

一个开源的语言十分流行是一件好事。但不幸得是,它不是一个伟大的语言。我希望所有的问题能有一天得到解决(也许在PHP6?),然后我们就将拥有一个开源语言,他既开源,又好用。

到现在,当你要启动一个多于5个脚本页面的项目的时候,你最好考虑C#/ASP.Net 或者 Java/JSP或者也许Python同样是一个更好的选择。

时间: 2024-08-03 23:10:51

为什么PHP令人不爽(对于大型系统)的相关文章

高性能的大型系统经验 -- 将数据分类、并缓存

    对大多数大型系统而言,数据库往往是最容易出现瓶颈的地方,而通过使用恰当的缓存技术可以非常有效地减轻数据库的负载.          将系统中用到的所有数据进行分类,分别对待不同种类的数据而不是一视同仁,有利于正确地做出缓存哪些数据.以及如何缓存的决策.     我通常将系统中用到的数据分为四类:恒定不变的数据,只发生增量的数据,偶尔改变的数据,经常改变的数据. (1)对于恒定不变的数据,采用普通的恒定缓存,即这种缓存在系统启动后初始化一次就不再改变了. (2)对于只发生增量的数据,采用智

中大型系统架构组合之EF4.1+ASP.NET MVC+JQuery

EF4.1已经推出有一段时间了,它给人的第一吸引力就是比LINQ TO SQL更加适合大型项目,它的封装更加紧密,操作也更加灵活,而且弥补了LINQ To SQL的最大不足,可以支持多种数据库.   EF4.1+ASP.NET MVC+JQuery 第一先说一下EF4.1: 我们数据层OR/Mapping采用EF4.1来实现数据的持久化 我们必须要对EF4.1进行一个封装,把对数据的操作限制在DATA层,不能向上一层暴露太多实现的细节,这样作是安全的,层次分明的. 对数据操作有一个泛型接口来实现

大型系统上PHP令人不爽的九大原因

我在过去的四年里一直致力于PHP应用的开发.PHP确实十分容易编写.但是PHP也有一些十分严重的缺陷. 下面我会给出我的理由,为什么PHP不适合于比小型业余网站更大的网站. 1. 对递归的不良支持 递归是一种函数调用自身的机制.这是一种强大的特性可以把某些复杂的东西变得很简单.有一个使用递归的例子是快速排序(quicksort).不幸的是,PHP并不擅长递归.Zeev,一个PHP开发人员,说道:"PHP 4.0(Zend)对密集数据使用了栈方式,而不是使用堆方式.也就是说它能容忍的递归函数的数量

高性能的大型系统经验 -- 数据查询与分页

     本文讨论针对大型数据表(记录数2千万以上)进行数据查找与分页的可行的高效方案.      首先,恰当的索引是必须的.      没有索引的支持,在大数据表中进行查询是不可思议的.关键点在于如何创建索引? 1.建立正确的聚集索引(clustered index).由于聚集索引的叶子节点就是记录本身,所以选择哪个索引为聚集索引非常关键.通过聚集索引扫描记录更快. 2.根据你的系统的需求总结常用的单个查询条件或综合性的查询条件,对于常用的单个查询条件建立单列索引,对常用的综合性查询条件建立联

CSDN社区问答第4期:曾宪杰 大型网站系统与Java中间件

问题描述 本期的社区问答(5月19日-5月25日)我们请来了<大型网站系统与Java中间件实践>一书的作者曾宪杰(华黎)为大家解答关于大型网站和支撑大型网站架构的Java中间件.分布式系统方面的问题.曾宪杰,淘宝花名华黎,现任淘宝技术部总监.2002年毕业于浙江大学计算机系.2007年加入淘宝网平台架构团队,负责构建淘宝自主的消息中间件系统,同期主导了淘宝数据层的创建,这两个产品也是淘宝中间件中较为重要的两个.2010年下半年起开始负责整个淘宝中间件团队,帮助团队成为业内知名的Java技术团队

SQL Server大型服务器:伸缩性、可用性与易管理性

简介 随着电子商务.在线商务应用.商务智能等领域的迅猛发展,许多成功的企业都在对其在线应用进行扩展.目前,每一个Internet或企业内部网络用户都是一个潜在的客户,因此,应用面临着巨大的用户和事务负载.绝大多数企业都在建立大型服务器,以便管理数以吉计的信息并为数以百万的客户和用户提供支持.在此过程中,数据库系统已成为这些大型服务器的核心. 可伸缩式系统为您提供了一种通过添加更多硬件设备的简单方式来扩展网络.服务器.数据库及应用程序的途径.可伸缩式计算机系统可在无需修改应用程序代码的情况下扩大应

考虑把大型项目拆解成微服务吗?

本文讲的是考虑把大型项目拆解成微服务吗?[编者的话]本文理性的讨论了拆解大型项目到微服务的过程,讨论了拆解过程中会遇到的问题和编程语言的选择,并给出了作者自己的建议. 微服务是处理臃肿.凌乱系统的一剂良药.然而,拆解一个大型项目为一系列的微服务所付出的代价是值得的吗?现在存在一些优点和缺点,那么微服务的哪些特点吸引了众多公司和开发人员呢? 最常见的应用场景是将一个大型系统切换到基于微服务的基础设施.我倾向将这个过程称为"分解"应用程序,因为我们把紧耦合的代码分解成多个小的服务.这包括了

ERP系统选型时的三条主线

ERP在国内的推广.应用已经有20多年的历史,可是直到今天,许多企业CIO还在为此困惑.迷茫,甚至有些绝望!的确,ERP给一些企业带来了荣耀和辉煌,可是也让不少企业也深陷困境,CIO为此也倍受自责. 在20年的历程中,关于ERP实施成功或失败的讨论已经连篇累牍,但是经验毕竟是有价值的,也正是这些宝贵资源让CIO不断推动企业管理信息化的发展和革新,所以当CIO真正把自己放在一个等待医治的位置上,去领会和类比成功者以及失败者轨迹的时候,失败的故事肯定会少一些! 选型好比战略,实施则是战术,在错误的战

性能测试知多少---系统架构分析

有些事儿一旦放一放就难再拾起来,突然发现<性能测试知多少>这个系列两月没更新,关键时我都不知道啥时候放下的,总容易被各种技术所吸引走,如饥似渴的想学更多的东西,这几天一直有朋友问我为啥不写了,我才意识,事情要一样一样做,我现在要把这个系列完成.   之前有对性能需求进行过分析,那篇主要从项目业务.背景等角度如何抽丝剥茧的将项目的需求抽离出来.在我们进行需求的时候也需要对被测项目的架构有一定的认识,如果不了解被测系统的架构,那么在后期的性能分析与调优阶段将无从下手.   简单系统架构介绍