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

请你引用下,我什么时候否认了java 比ror成熟了?
如果有,那肯定也是单指互联网方面.
java的互联网成功案例很多? 可能不那么多吧?

正是因为总得看来java的确比ror成熟, 所以才有人说"成熟"也许是java最后一块遮羞布.
如果你读懂了这个比喻,你应该知道,它一方面承认了java的成熟,另一方面也批判了这种只拿成熟出来说事的行为.

的确,这个说法有点重.... 太有个人色彩.... 有些java程序员看了可能受不了......但我认为它还是能说明些问题的....

我觉得java太依靠成熟这个有点,其实是很危险的.成熟能依靠多久啊?   不能老拿来说事啊??? 你说对吧???

何况做互联网, 你真认为java更成熟?

杨祥吉他们那个公司在成都，你应该和他联系一下

过去二十年哪个新技术出来不是同样的废话
成熟等价于低价民工。有人喜欢做低价民工你干嘛拦着？

静态编译语言对于大规模的项目协作来说，很多情况下是比动态脚本语言好很多。不过你这个例子举的太糟糕。即使是Java/C++，你这个if条件语句也是一个合理合法的表达式，编译根本就不会有任何警告信息。

既然提到我了， 这个我要澄清一下！

第一、ruby的内存分配机制尽管比较粗鄙，但是没有想象当中那么差劲。

其实现在互联网行业当中，使用ruby的大规模应用比比皆是，twitter，37signals，Engine Yard，包括Amazon的一些东西。所以ruby做互联网应用从GC的角度来说，是肯定没有问题的。

第二、JavaEye的确有一个监控ruby进程的脚本，但最后证实内存泄漏并非ruby引起的

JavaEye曾经出现ruby进程总是内存泄漏的现象，我曾经认为是ruby的GC造成的。但是后来我用了一个巧妙的办法，就是这个：监视Rails进程内存泄漏的技巧，找到了内存泄漏的罪魁祸首。真正的原因是我们有几个处理大数据量的代码犯了愚蠢的错误造成的，具体是什么愚蠢的错误，就不足为外人道也了。

尽管由于幽灵指针造成的ruby存在轻微的内存泄漏，但事实上除非你用ruby做后台服务，长期不间断运行，否则这个问题并不会影响到你，特别是Raisl应用来说，基本上不会受影响。

当然我很乐见MBARI补丁现在正在被合并到ruby 1.8.7的trunk上面去。只不过这个补丁现在存在一个怪异的不定期出现的CJK编码转换的兼容性问题，我正在进行大数据量中文编码转换的测试，以寻求能够重现该错误，并且尽早提交这个issue。否则等下一个ruby 1.8.7 patch level版本正式发布以后，倒霉的就是我们中国的Rails用户了。

第三、Java的GC应该是目前最成熟的虚拟机GC实现了。否则也不会出现jruby项目。但是虚拟机成熟不代表在所有的应用领域都很成熟。在Web开发框架方面，Java确实很令人失望。

这本来是一个探讨PHP框架和Rails的话题，怎么又跑题到Java vs Ruby上去了？ 跑题的家伙自己出来自首吧。

如果说语言的比较和借鉴是一个挺有意思的话题的话，那么搞xx PK xx就很无聊了。我们JavaEye网站实际上同时用到了Ruby，Java和PHP三种编程语言：Ruby用来做Web层，Java用来实现后台的全文检索服务器，而PHP用来实现邮件列表和邮件群发功能。所以我爱ruby，但是我也爱Java和PHP，如果将来JavaEye又用上了Python，你也不要吃惊，编程语言就是工具，工具是被你使用和玩的，而不是控制和玩你的。

编程语言就是工具，工具是被你使用和玩的，而不是控制和玩你的。

曾经被玩过....

我认为，系统开发的目的是满足功能需求，从而带来效益。至于用什么语言实现，依需求而定了。功能需求和系统思想更应被关注。

谢谢，我在努力。我水平实在是很菜，绝对很菜
不过事实上，我确实没看出你水平高在哪里，当然，凭你那5颗星你技术肯定比我强(有3个精华贴的人，的确让我佩服)。但总不能不让我表达意见吧。
事实上，我当时确实不知道依赖注入到底有什么好处，不过现在也知道了，也就是一天工夫吧，这里感谢下robbin，不是被他鄙视，我确实也不会去深入了解为什么要用依赖注入。
问题是我当时被robbin鄙视能学到一些东西，希望你鄙视我的时候也给我带来一些新东西，你能不能指教一下我我哪里说错了。
最后我觉得你心胸比较狭隘，你自己是不是也这么觉得？


我再回过头来看了下我原来那帖子，红字部分你能不能举个例子我怎么用seam被你称作一绝？

我有罪，保证以后不发任何口水贴。貌似最近过年很浮躁，水了很多贴。

对这个讨论中有关 php 和 rails 的部分非常感兴趣，因为我自己就在做一个开源 PHP 框架（http://qeephp.com）。所以下面的话大家可能觉得不够中立，不过这个世界上本来就没有绝对的中立，不能接受这一点就用往下看了。

-------------------------------------

不管是楼主，还是其他回复，都一种“不准确”的看法：PHP 框架在抄 rails。

之所以说“不准确”，是因为部分 PHP 框架在抄 rails 是事实，但更多的是抄 rails 的设计思想。就像 robbin 举的几点，PHP 毕竟和 Ruby 有非常大的区别，如果不能吸收 rails 的思想精华，单纯的抄袭结构和功能，最后就是个不伦不类的怪物（例如 PHP on Trax 这个 rails 的 PHP 克隆）。

一些误解：

但是我认为大家也对 PHP 和 PHP 框架有许多误解，一一阐述：



我认为 PHP 能够大行其道的根本原因是：PHP 是一种专门针对 Web 开发设计的语言。

如果能够接受这一点，其他都很好解释了。PHP 对于 Web 常见的需求都有内置的实现，加上容易学习的语法和简单的运行模型，造就了一大批初级 PHP 开发者。这就像 Visual Basic 一直是用户量很大的桌面应用开发语言一样，PHP 有针对性的设计目标成就了 PHP 在 Web 领域的地位。

但是水能载舟亦能覆舟，大量初级 PHP 开发者拒绝 PHP5 带来的新思想、新模式。在 PHP 社区所有关于过程式还是面向对象的争论都会演变成口水战，虽然绝大部分 PHP 开发者根本不懂面向对象。这也是 PHP 发展中的一个大问题。

但是，面向对象是阻挡不住的趋势，迟早 PHP 社区会接受这一点的，包括 PHP 的创始人（虽然他是创始人，但显然已经被 PHP 社区边缘化了，PHP 新版功能规划等根本没他说话的地儿），各种 PHP 开发框架也在不断的往这个方向靠拢。



PHP 框架另一个令人诟病的地方就是性能问题，几乎让人认为 ： PHP + 框架 = 性能差。
但造成这种问题的根源根本不是 PHP 或者框架，而是这些 PHP 框架设计和实现造成的，drupal 为什么慢也是这个原因。

国外，CakePHP、Zend Framework、Symfony、Code Igniter 是目前使用最广泛的四个框架（排名没有先后），性能上最快的是 Code Igniter。但如果和国内的框架相比，即便是最快的 Code Igniter 也是很慢的。所以这是不同的设计思想导致的后果。



对于大型应用，用 java/c++ 做中间件承担业务逻辑处理，是必然的。即便是 ruby 也只能这样做。但是这不等于对于规模更小的应用来说，PHP 就不能实现具有复杂逻辑的应用。

说到这里，不得不说现在许多 PHP 框架都走入了误区：鼓励开发者在应用层实现业务逻辑。这些框架中，所谓的模型只是对数据表的简单封装，几乎都是 TableDataGateway 模式（参考 PoEEA），CakePHP 甚至把 TableDataGateway 和 ActiveRecord 混合到了一起。这些框架开发的应用有一个很典型的特征：控制器的代码特别多、程序逻辑之间传递的都是数组。

这种错误的做法，业务逻辑本该是模型的责任，结果却给弄到控制器或者单独的 Service 对象中去了，而业务数据都用数组来传递。这和早些年反思 Java 的 DTO、Service 模式不正是一样么。所以它们实际上在走一条老路。