PHP框架的繁荣是正确的发展方向吗？

一些观点，请大家批评指正。

大部分 PHP 开发者不懂面向对象

不客气的说，大部分 PHP 开发者根本不懂什么是面向对象。他们也许会写一大堆 class，再用上很多种设计模式，但是从全局看，他们的思考方式仍然是过程式的。随便在网上搜索几篇 PHP 面向对象的教程、文章之类，都可以看到这种情况。

正是这种情况的存在，所以有几个错误观点一直在 PHP 社区广泛流行：
1、用了框架就是面向对象
2、封装了数据库操作，就叫 ORM，或者干脆认为 PHP 不可能实现 ORM

第一个观点，导致大部分基于框架开发的应用都是“伪OO”的。这些应用空有 class 构筑起来的外观，却没有 OO 的灵魂。业务逻辑要么在控制器中，要么被写成一个个独立的函数。而第二个观点在初级开发者那里很有影响力，因为他们并不具备判断这种结论正确性必要的知识。但是因为 PHP 社区的大部分开发者也正是他们，所以这些错误观点的支持者是如此众多。

关于第一个问题，我就不多说了。重点说说第二个问题。


PHP 真的不能实现 ORM？

对于这个问题，我的答案当然是否定的。PHP 不但可以实现 ORM，而且可以做得很好。
说到这里，不得不提我主持开发的 QeePHP 框架了，虽然有点自吹自擂的嫌疑。

ORM 在我看来，是为对象及对象关系提供持久化服务的工具。很多开发框架都实现了 ActiveRecord 模式，实现对象的持久化并不是问题。但关键在于如何维护“对象关系”这一点上。如果一个 ORM 不能很好的维护对象间的关系，那么这个 ORM 就是个太监，最重要的东西没有了。

以作者、书籍、读者、评论四个对象的关系为例：

作者 <--- 多对多 ---> 书籍 <--- 多对多 ---> 读者
 |                     ^                     |
 |                   一对多                  |
 |                     |                     |
 从属 --------------> 评论 <--------------- 从属

作者可以写多本书，而每本书可以有多个作者。每本书有多个读者，每个读者又可以读多本书。
读者和作者都可以对书籍发表多个评论，但每个评论只能属于一本书。

在上面的关系网中，从任意一个对象出发，都应该可以导航到任意一个其他对象：

作者 -> 书籍 -> 评论 -> 评论人（读者或作者）
书籍 -> 作者 -> 作者的评论 -> 评论所属的书籍 -> 该书籍的读者....

对于一个面向对象系统来说，上面跟随关系进行导航是必须的，ORM 必须能够支持这种导航。
而 QeePHP 设计之初的主要目标之一就是支持这种对象关系网的自由导航。只有做到了这一点，才能真正实现将业务逻辑封装在模型中的目标。

一段 QeePHP 应用代码：

$author = Author::find($author_id)->query();
echo '作者: ' . $author->name;
foreach ($author->books as $book)
{
    echo '该作者的书籍: ' . $book->title;
    foreach ($book->readers as $reader)
    {
        echo '读者: ' . $reader->name;
        foreach ($reader->comments as $comment)
        {
            echo '该读者评论过的书籍: ' . $comment->book->title;
        }
    }
}

上面的代码演示了采用一种“自然”的方式来访问关联对象的能力，而这种能力是面向对象应用必须的。
RoR 能够流行开来的重要原因之一（在我看来实际上是最重要的），不也是因为其为领域模型提供的强有力支持么。

面向对象就一定是好的，ORM就一定是适用的？

都是一种工具罢了。看应用需要了。

既然是框架实现的问题，那为了实现Java、ROR等WEB框架同等或者近似的丰富功能，有什么已经存在的PHP框架证明其性能超过、等同或者接近这些框架的性能？

另外，PHP本身的运行机制没有制约它的框架或者应用的性能吗（不加特殊的优化机制如APC等）？

看来遇到高人了

PHP实现MVC 太简单了，无非就是index.php入口文件收集所有请求，然后分发

我之前做的PHP项目基本都是用了这种方式

收到多谢指教。我大致了解你的意思了

Java、RoR 我并不熟悉，所以没有做过性能测试。但是 PHP 框架的性能问题并不是 PHP 语言本身造成的。就像 Java 一样可以做出很慢的框架和很快的框架，同一种语言下不同的设计和实现会导致差异很大的结果。节后希望能够做一个更全面点的性能测试，到时候还希望熟悉 Java、RoR 的朋友提供帮助。

单纯从语言角度看，PHP 比 Ruby 快很多，这一点是毋庸置疑的。而 Lighttpd + FastCGI + PHP 的性能也很出色，再配合 APC 等 opcode cache 和数据库持久连接，能够把 bootstarp 的成本降到最低。如果加上 memcached，还可以进一步提高性能。

至于你说不用 APC，我想没必要这样比，因为 APC 本就是 PHP 的一个扩展，可以轻松添加到 PHP 运行环境中。难道你的 Rails 应用不会借助 memcached 来提高性能么？

不要把框架和 MVC 划等号 -_-#

Flea,Qee的作者都来捧场了. 热烈欢迎啊. 你就是传说中的廖老大吧? 哈哈~幸会幸会....

的确你说的没错, 框架的效率肯定是和实现的方式有很大关系的.

但对于php来说,这个下降性能的最主要原因是不同的实现方式 还是是robbin所说是php工作原理?谁是降低性能的大户?

希望廖老大能深入分析分析... 也让我们这些不太懂php的能学习学习 ^_^

顺便祝春节快乐...牛年大吉....

我认为php的工作原理负主要责任. 它的工作模式制约了复杂php的框架的发展