Java、RoR、PHP，一个都不能少

前几年一直弄Java，半年前跟风用过一段时间RoR，最近在搞PHP。
现体会如题：Java、RoR、PHP，一个都不能少。

各种程序设计语言最终的归宿，其实是由最初的设计思想所决定的。
C定位于底层，成就了时至今日的底层霸主地位；VB的初衷就是让Windows开发简单易用，故至今仍然占牢其地盘；Java最初瞄准的是跨平台和解决复杂问题，这一目的已然达到，并正在发扬光大；PHP则是追求简单、直接的Web开发，这一出发点成就了其互联网应用霸主的地位。那么RoR的优势是什么呢？笔者从实践中体会到，其根本的优势在于让OOP变得简单规范。

笔者在三个月前发了“RoR的正确定位”（见http://www.iteye.com/topic/75167）后，便投入了对PHP的实践中，体会如下：
1、PHP极其简单直接，对GET、POST、SESSION、SQL的直接操控可以适应多种页面需求和变化；
2、传统的PHP是过程式函数编程，简便灵活，但结构化、规范性不足。PHP5以后引入了OOP，框架也火热一片。但两种方式混编容易造成困扰，且框架编程发展较晚，尚未形成成熟统一的实践（如SSH）；
3、PHP入门极易，笔者以前一周即学会，一个月基本上能应付小系统开发，这对于个体户和小作坊这类的开发群体无疑是最适合的；
4、PHP发展多年，类库和API极其丰富，能满足多种需求。
5、空间超多，布署代价极低。光这一条就可成为很多小系统的最爱。
综上所述，PHP是小系统的首选，某些特殊要求的页面也可采用。

RoR在JE上已经火了一年多了，其间无数论战，而RoR的爱好者们至今坚挺，这足以说明RoR不只是花瓶或玩具。在实践中，笔者体会到RoR的特点如下：
1、RoR的威力最主要的来源是“惯例重于配置”，而其“惯例”基本上是多年来Web开发所积累的最佳实践。大家不要小看了这种规范性，所谓“不以规矩，不成方圆”。像应用MS技术的团队，大家不要再胡思乱想，只要遵循MS的标准和规范，即可开发出不低于业界平均水准的系统。
ruby本身是极其灵活的，容易导致混乱，但rails这种天才式的框架解决了标准化的问题。大家不必再为了一个问题去参考十多种方案和实践，浪费太多的时间和精力。在RoR，方案只有一种，而实践上也只需搞定depot即可过关。从数据库设计、ORM、MVC以至于目录结构，全都是统一的。这实在是省心省力，时间和精力都可以放在业务逻辑上了，这不正是以前J2EE和.NET所宣扬的吗？
2、RoR相对Java和PHP这些老前辈，火得比较晚，类库还不够丰富。这就需要大家充分发挥聪明才智，并积极向开源社区作贡献。这一点希望RoR铁杆们多努力，让RoR的类库在未来三五年内达到Java和PHP的水平。届时RoR能不能向Java和PHP全面叫板，未为可知。
3、缘于RoR良好的结构化和OOP，建议大家做中型新系统时采用RoR。历史系统大多数数据库设计不符合RoR的惯例，手工配置会浪费太多时间，不如下点狠心重新设计，一劳永逸。
综上所述，RoR应当在中型系统取得成功。如果你已经习惯了OOP、ORM和MVC，那就一起努力吧！

Java在大型复杂系统的优良表现有目共暏，最主要的是“强”和“稳”，本人不再多述。各位Java同道在RoR之余，大可钻研一些深层次的复杂问题，以应大型系统集成的需要。


谈了那么多，全是可以跑在Linux上的开源或准开源技术，原因在于笔者在五年前已加入开源技术的死忠团。但这几年，每当有困惑的时候都学一些C#这类的技术。C#在笔者看来，定位在于大小通吃，表现比较中庸。也就是说做小系统不太繁，做中系统不太难，大系统也可以做。但中庸也是要付出代价的，这导致用C#做系统不如PHP直接灵活，中型系统不如RoR规范统一，大系统不如Java强健。
当然，实践中还是有很多MS的死党，如果您对MS技术的安全性和稳定性抱有足够信心的话，C#的确可以达到一次学习，多方适用的目的。

开源领域，要想学一种技术大小通吃，很多时候必须一钻到底，承担类库或框架开发的责任。由此可以产生专项技术超强的高手。而如果您同时掌握PHP、RoR、Java，也可以比较小的代价做到大小通吃，快速搞定各类应用开发。何去何从，应该由开发者及团队所面临的环境和场景而定。

一项专精，还是三者兼备，相信聪明的读者已经有了答案。

楼主分析的相当清晰
但是楼主怎么断言ror不能做大系统呢？是楼主做过失败了 还是仅仅是学习了ror之后的感觉呢？ 我看半天也没看明白

看来是我没说清楚了。RoR不是说不能做大系统，而是说当前不适合做大系统。
大系统安全性、事务、异构集成要求很高，开发效率的要求尚在其次，这样RoR目前的优势就不大了。如果一定要用RoR硬上，相信顶尖的高手们是一定可以做到的，但费时费力。这时候明智一点的做法就是用现成的Java。
当然爱钻牛角尖的同道们大可攻下这些难题，并贡献给开源社区，那样再过几年大家一样可以很方便地用RoR做大系统。本人主攻应用程序开发，主要用的是现成的成熟技术，这类高精尖的螃蟹的确是没本事吃。

其实现在有了WebService，复杂如SOAP，简单如REST。今后不论采用何种服务器端技术，相信都能互通互连（参本人拙作“看好Ajax+WebService”http://lgx522.iteye.com/admin/show/99853），各阵营的同道们大可放心了。
但有一点一定要注意，那就是不论采用何种技术和方法，也不论是用DB建模还是OO建模，一定要合格，这方面号召采用RoR的数据库设计惯例。

ruby在日本流行很多年了，日本这个注重惯例的民族，早就把ruby 和rails的优点应用于java,好一点的java 框架产品，比rails还智能，而且是图形界面的，rails最大的优势就是免费，另外小规模开发效率高。
目前日本的低端web空间，只要支持php的，一般都支持ruby，而支持java的空间都贵得离谱，所以ruby的成本是最大的优势，如果有几个大型网站成功导入ruby成功后，相信会抢占一部分java的市场。

楼上的能不能说说日本流行的java框架呀，据我所知，有一个seasar2,是spring,rails的混合体，在日本大项目用的很多

日本大公司的项目用开元框架的反而少...一般都有自己的专用框架...

的确如楼上所说，日本的框架很多，只要能说得上名的公司，如日立，NEC，富士通，佳能等，都有自己的框架,当然很多就是封装一下通用的框架，只不过加强了日文的支持。

“Seasar2”就是一个“轻量级容器”，面向无法摆脱“Java 应用开发”之烦恼的所谓“开发者”，它能够保证开发的“高生产率和高品质”。并且同“其它轻量级容器”不同的是，“完全不需要书写设定文件”，“就算是应用程序发生改动也无需再次起动即可直接识别变更，因此具有脚本语言的灵活性”。

为了不用写设定文件也能够运行，Convention over Configuration的思想得以采用。Convention over Configuration就是指，“只要遵守一个适当的规约，即使不用进行非常麻烦的设定，框架结构也可以自动替我们搞定的思想”，这一思想是Ruby on Rails中所倡导的。Seasar2的Convention over Configuration是从Ruby on Rails 那里得到的提示而产生的。

使用Seasar2的话，对于仅仅需要维护数据表这样简单的应用，可以在不到3分钟的时间里作成。

应用程序发生改动之时也无需启动便可立即识别变更的机能在Seasar2里被称为HOT deploy。


这个被称为 日本発の「世界最先端」的框架，是开源的。
http://www.seasar.org/

分析的很好, 不同的项目不同的需求, 可以采用最合适的方案, 而不是最流行的最顶尖的方案.  另外大家可以看看GROOVY和GRAILS, 在不"背叛"JAVA阵营的前提下, 熟悉熟悉DYNAMIC PROGRAMMING =]

投这些票的朋友是看不懂还是特NB??

既然公开发表的帖子就应该让别人发表自己的看法 想法，听听不同的声音
但那些投入门 隐藏 或者 良好 精华的同学能不能给出你们的理由和想法，让大家互相学习一下
总不能让lz死的不明不白吧