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

07-07-24 lgx522
              

前几年一直弄Java,半年前跟风用过一段时间RoR,最近在搞PHP。

现体会如题:Java、RoR、PHP,一个都不能少。

各种程序设计语言最终的归宿,其实是由最初的设计思想所决定的。

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

笔者在三个月前发了“RoR的正确定位”(见http://www.javaeye.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,也可以比较小的代价做到大小通吃,快速搞定各类应用开发。何去何从,应该由开发者及团队所面临的环境和场景而定。

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

              

1
diogin
2007-07-25 14:51

php不只是做小网站的首选。facebook这样的超级大站也用php :)

lgx522
2007-07-25 17:55

大站面临的主要问题是性能,各位可以参看http://www.javaeye.com/topic/94774

这篇帖子讨论的大、中、小之划分,主要根据是复杂程度,而非规模。

简单一点说,就是如果涉及到高安全、多事务,异构系统集成,那就是大系统;而对结构、扩展性、维护要求高的,那就是中系统;而短期内基本上可以用就OK的,那就算小系统。

另外说明讨论的是现阶段适合不适合做,而不是能不能做。也就是说各取所长的问题。

banq
2007-07-26 10:43

楼主的意愿是比较好,当前几个大佬一个都不得罪,全部使用,但是必须从用户角度真实考虑,系统规模总是不以人的意志为转移变化的。

今天的中型规模不小心过几年就是大型系统,如果采取不同语言体系,他们平滑过渡如何?也就是可伸缩性的衡量,很多人没有将可伸缩性放在架构设计首位。

重写软件不只是软件工程师的工作,还是导致整个软件操作人员(这些往往是企业重要岗位人员)习惯甚至思路改变,这种改变就象对人进行抽筋换骨一样。

让我们回到当初为什么使用Java的讨论上:国外很多大型企业有几十年的信息系统发展历史,但是他们逐步发现:在不断发展变化的今天,硬件可以通过大资金投入更换,只要有钱,就能换硬件,但是软件就不是这样,不是有钱就能换的。

因为企业软件说到底不只是纯粹软件,如果大家了解软件的开发是从业务建模到软件实现过程,你就会发现:软件本身没什么了不起,但它反映的业务建模概念和业务特点是最重要的,这个结果是多年来发展的混合结果,这是一个企业最宝贵财富,是再高价格换不来的。而这样一个结果不是凭无论多少高手都无法复制重写的。

如果同意上面这个观点,对软件的可伸缩性这个重要性就会有深刻体会(说到底还是需要企业信息化的丰富经验),那么选择一个语言其实是选择一个平台,这个平台能否象伸缩舞台那样可以伸缩自如就成为很重要的因素。

[该贴被banq于2007年07月26日 13:23修改过]

lgx522
2007-07-27 11:44

同意banq的说法

其实banq兄的说法里,所指的系统已经是大系统了。而一般能够称得上“企业级”的系统,也都是本文里说的大系统。这个领域,Java当前是首选。

做这类应用,大家不要想偷懒。笔者前些日的“发扬EJB/Spring的光辉思想,将组件化进行到底 ”对此已有说明。

而当前中小企业,尤其是民营企业也存在着信息化的问题。他们未来的前景难以预见,客观而论,绝大多数不会成长为真正的大企业。对此本人的意见是以比较简单的方案(PHP、ROR)和比较低的代价,做这类企业的信息化。

以免现在大家为“大”系统争破了头,搞出一大堆华而不实的东西坑害客户;而忽视了中小企业实实在在的低价、短周期需求。

这就明确了应用的倾向,其实就是如果要求长治久安的业务逻辑,那就要用Java来做;短期性的业务逻辑,则可以采用开发快速为先的方案。

其实还有个目前不切实际的东西,那就是通过WS,可以在理论上解决业务逻辑重用的问题。但前提是不论PHP、Ruby、Java,业务逻辑设计都要合理并要能重用。如此高要求的话,使用什么具体技术就都不容易短平快了。

顺便请教一下banq对REST的看法。

本人的看法以为可以解决内部系统的异构集成问题,至于高安全要求的外部系统集成,只怕还是得用SOAP。

REST目前还未真正大量应用,是否会出现SOAP以前的性能问题,要拭目以待。

(如果SOAP前几年不是因为性能和复杂性问题而龟缩的话,大家或许已经不必苦恼了。)

[该贴被lgx522于2007年07月27日 11:46修改过]

4Go 1 2 3 4 下一页