重新认识PHP框架

相关推荐

重新认识PHP框架

　　有很多我们已经认识和了解的东西，有时候又会带给我们不一样的感觉，以下是百分网小编精心为大家整理的PHP框架的重新认识，从一个全新的角度来诠释PHP框架。更多内容请关注应届毕业生网!

　　有人认为，PHP是每次请求都要初始化资源，这个开销非常大。由此，PHP不适合使用开发框架。对于PHP，确实没有类的持久化，使得每次请求都要初始化资源，但是，这并不是开销的主要问题所在。最主要的问题，是在于开发PHP框架的人，对PHP本身的特性了解多少。最简单的，MVC需要检测UA，如果使用PHP自带的get_browser函数，那肯定是死定了。因为，使用上的方便与简单，导致的是性能的开销。认为不可使用PHP开发框架的，还有的观点是：由于需要每次请求的时候初始化整个框架。其实，这也是一种误解。如果好好看看PHP源码，就会了解，PHP是按请求加载需要运行的文件，并不是整个框架。所以，对于框架本身，哪一种框架内核代码时越小，性能越好。

　　还有观点：由于PHP这种每请求初始化资源的机制，也造成了PHP添加跨请求的高级特性相当困难。其实，跨请求本身，要看在哪一个层面。PHP提供了各类加速的缓存机制。虽然PHP的类是由于目前序列化函数仍有限制，不能持久化，但数据缓存对PHP的加速是相当快的。所以，认为由于这一限制，就使得PHP 只能是一个保持在一个比较简单的web语言上面，这无疑更是错误的。PHP不乏大型的高速与高效的网站。并不是这些网站底层就没有框架。

　　另外，还有轻信什么测试的结果。对于测试结果，我觉得，没有一丝一毫的可信度。我们无法相信这些测试结果，主要原因有这么几个方面。其一，PHP环境配置，是不是最优化配置?第二，测试结果中所选框架，是不是最优框架?仅拿CI与CAKE两者来说，CI的日志，没有多种输出，只有文件输出。这对于大型网站的管理是极不方便的。但是，如果将其改用LOG4PHP，那性能上的损失将会是多少，是不可想象的。原因在于，LOG4PHP是完全照抄的Java。至于CAKE，更是完全照抄RAILS。完全不顾及PHP的性能与语言本身的特性。比如最简单的，大量静态方法的使用。势必造成以空间换时间。CAKE中无处不在的静态方法，导致了内存中堆积大量的类。这种以空间换时间，是速度加快了，还是性能损失了，有多少人真正系统测试过?CAKE让RUBY的人了解PHP是对PHP的一个促进，同时，RAILS框架，也使得PHP框架得以注入新的血液，增加了新的开发思路。但，完全照抄是 PHP目前最大的悲剧。这个当中的经典之作：CAKE：RUBY ON RAILS， SMARTY： Java STRRUTS LOG4PHP：JAVA LOG4J，可悲的是，写这些抄袭之作的作者，都是对PHP不太了解，大量照搬RUBY，JAVA中的算法与函数，有些可以算是翻译，比如， LOG4PHP中的PROPERTIIES文件的处理就是这样，不必再举更多的实例了。为什么不能把JSF，或TYPESTRY也抄到PHP中，这是因为，如果没有很好的PHP功底，这几乎是不可能的。因为，这两个东西，如果也是照抄过来，势必慢如蜗牛。

　　再有，梦想不用PHP框架开发大型网站，肯定是错上加错。WORDPRESS，DISCUZ这类无框架，无架构的极端糟糕的代码，网上已屡见不鲜。

　　要访问数据库，最小的需求，也要把数据库访问封装成一个类吧?要进行错误与异常管理，也需要一个类吧?如果是大型的网站，总要有错误日志输出，以方便调视与运行监视吧。所以这些，拼一下，也算是PHP开发框架呀。

　　看样子，否认PHP应当有框架的人，肯定也就认定，PHP做不了大网站。或者说，认定，PHP做大网站，也是垃圾架构。这可能是太武断了。

　　凡认为PHP是反框架的，实际上，是不了解PHP语言的一些瓶颈在何处，无法写出高效的框架，所以，才这样认为的。

　　【拓展阅读】　PHP 安全编程建议

　　简介

　　要提供互联网服务，当你在开发代码的时候必须时刻保持安全意识。可能大部分 PHP 脚本都对安全问题都不在意，这很大程度上是因为有大量的无经验程序员在使用这门语言。但是，没有理由让你因为对你的代码的不确定性而导致不一致的安全策略。当你在服务器上放任何涉及到钱的东西时，就有可能会有人尝试破解它。创建一个论坛程序或者任何形式的购物车，被攻击的可能性就上升到了无穷大。

　　背景

　　为了确保你的 web 内容安全，这里有一些常规的安全准则：

　　别相信表单

　　攻击表单很简单。通过使用一个简单的 JavaScript 技巧，你可以限制你的表单只允许在评分域中填写 1 到 5 的数字。如果有人关闭了他们浏览器的 JavaScript 功能或者提交自定义的表单数据，你客户端的验证就失败了。

　　用户主要通过表单参数和你的脚本交互，因此他们是最大的安全风险。你应该学到什么呢?在 PHP 脚本中，总是要验证传递给任何 PHP 脚本的数据。在本文中，我们向你演示了如何分析和防范跨站脚本(XSS)攻击，它可能会劫持用户凭据(甚至更严重)。你也会看到如何防止会玷污或毁坏你数据的 MySQL 注入攻击。

　　别相信用户

　　假定你网站获取的每一份数据都充满了有害的代码。清理每一部分，即便你相信没有人会尝试攻击你的站点。

　　关闭全局变量

　　你可能会有的最大安全漏洞是启用了 register_globals 配置参数。幸运的是，PHP 4.2 及以后版本默认关闭了这个配置。如果打开了 register_globals，你可以在你的 php.ini 文件中通过改变 register_globals 变量为 Off 关闭该功能：

　　register_globals = Off

　　新手程序员觉得注册全局变量很方便，但他们不会意识到这个设置有多么危险。一个启用了全局变量的服务器会自动为全局变量赋任何形式的参数。为了了解它如何工作以及为什么有危险，让我们来看一个例子。

　　假设你有一个称为 process.php 的脚本，它会向你的数据库插入表单数据。初始的表单像下面这样：

　　运行 process.php 的时候，启用了注册全局变量的 PHP 会将该参数赋值到 $username 变量。这会比通过 $_POST['username'] 或 $_GET['username'] 访问它节省击键次数。不幸的是，这也会给你留下安全问题，因为 PHP 会设置该变量的值为通过 GET 或 POST 的参数发送到脚本的任何值，如果你没有显示地初始化该变量并且你不希望任何人去操作它，这就会有一个大问题。

　　看下面的脚本，假如 $authorized 变量的值为 true，它会给用户显示通过验证的数据。正常情况下，只有当用户正确通过了这个假想的 authenticated_user() 函数验证，$authorized 变量的值才会被设置为真。但是如果你启用了 register_globals，任何人都可以发送一个 GET 参数，例如 authorized=1 去覆盖它：

　　// Define $authorized = true only if user is authenticated

　　if (authenticated_user()) {

　　$authorized = true;

　　}

　　这个故事的寓意是，你应该从预定义的服务器变量中获取表单数据。所有通过 post 表单传递到你 web 页面的数据都会自动保存到一个称为 $_POST 的大数组中，所有的 GET 数据都保存在 $_GET 大数组中。文件上传信息保存在一个称为 $_FILES 的特殊数据中。另外，还有一个称为 $_REQUEST 的复合变量。

　　要从一个 POST 方法表单中访问 username 字段，可以使用 $_POST['username']。如果 username 在 URL 中就使用 $_GET['username']。如果你不确定值来自哪里，用 $_REQUEST['username']。

　　$post_value = $_POST['post_value'];

　　$get_value = $_GET['get_value'];

　　$some_variable = $_REQUEST['some_value'];

　　$_REQUEST 是 $_GET、$_POST、和 $_COOKIE 数组的结合。如果你有两个或多个值有相同的参数名称，注意 PHP 会使用哪个。默认的顺序是 cookie、POST、然后是 GET。

　　推荐安全配置选项

　　这里有几个会影响安全功能的 PHP 配置设置。下面是一些显然应该用于生产服务器的：

　　register_globals 设置为 off

　　safe_mode 设置为 off

　　error_reporting 设置为 off。如果出现错误了，这会向用户浏览器发送可见的错误报告信息。对于生产服务器，使用错误日志代替。开发服务器如果在防火墙后面就可以启用错误日志。(LCTT 译注：此处据原文逻辑和常识，应该是“开发服务器如果在防火墙后面就可以启用错误报告，即 on。”)

　　停用这些函数：system()、exec()、passthru()、shell_exec()、proc_open()、和 popen()。

　　open_basedir 为 /tmp(以便保存会话信息)目录和 web 根目录，以便脚本不能访问这些选定区域外的文件。