RoR可否替代J2EE?

最近在一本杂志上看到,使用Ruby on Rails开发Web应用十分高效,不知是否有人知道RoR最擅长哪方面的应用开发?与J2EE的比较?能否替代J2EE? 请高人指点!我始终认为我们目前所用的开发模式(使用J2EE架构+MVC模式,但未用EJB)效率不太高,想换一种架构。

Ruby on Rails是最新出现的Web开发方式。通过所谓的Rails框架,几个简单的命令,就可以生成一个缺省的数据表CRUD程序。但是Ruby on Rails在很多方面还是很不成熟的。至少在短期内,它还无法承担大型项目的开发。
在事务处理、分布式应用等高端和复杂的地方,J2EE还是最主流的选择,Microsoft.NET占据了剩下的部分。
Ruby是解释语言,这是它的优势,同时也是劣势。解释语言开发灵活,但是同时,在开发环境方面就差了。看看JavaScript吧,很多函数都要自己记。大家已经被Eclpse和VisualStudio这些产品养叼了,所以没有了一按“.”方法就弹出来、语法错误自动检查、自动重构这些功能,就感到相当麻烦。而且因为是解释执行,在执行效率上比较低,如果负载比较大的话,承受能力不如编译语言。
我估计你开发的多是中小项目吧?中小项目的业务逻辑很一般都很简单,表现层开发则占了决大多数时间。所以,你需要一个高速开发表现层的框架。
我给你三种选择:一是Microsoft的ASP.net。Microsoft的东西入门容易,表现层开发决大多数功能都可以通过拖拽实现。缺点是只能在Windows平台上实现。二是继续使用J2EE,但要选择一个新的表现层框架。1.JSF(JavaEE5官方标准),Sun为了和微软竞争,推出了Sun Java Creater2和最新的Netbeans5.5。它们都支持拖拽式开发JSF,缺点是资料比较少。2.Tapestry,相当不错的表现层框架,缺点是学习曲线太高,资料太少。3.Wicket,新出现的框架,用Swing的方式开发Web应用,学习曲线比较低,但目前资料太少,而且因为比较新,不够成熟,所以还无法承担大型项目开发。你可以发现,JavaEE在表现层的开发上,新的高效框架还是很多的。但都有一个致命的缺点,资料太少。可能是因为Struts统治的太久了吧。三就是你说的Ruby on Rails了。
具体如何选择,你可以自己比较。而且开发的时候,要根据客户的要求和你自己的情况综合考虑。

同意楼上

如果有人说“RoR会替代J2EE”,过于武断,RoR为什么会兴起,是因为一个叫Martin Fowler的人看上了它,MF是什么人?是所谓OO流派大师,其实我认为他是一个建模专家(分析专家),而非软件架构专家。

更重要的是:未来不是语言之争,而是建模语言之争,RoR虽然是一个好的建模语言,也就是很快能够表达建模意思,但是其代码架构不如Java深入和宽广。

小的应用使用ROR可以,如果这个小系统将来可能扩展到大系统,那么就要Java,到时再过渡Java平台,手术就大了,所以软件架构的可伸缩性很重要,软件是有生命的,是不断成长的。

关于RoR的快,这是一面之辞,如果牺牲相关设计质量,Java也能够达到相同的快速开发,例如Hibernate创始人开发的JBoss Seam,看看它的一个案例就可以。相关文章:

http://www.jdon.com/jive/article.jsp?forum=62&thread=27279

如果还觉得不算快,我设计的JdonFramework更快,分分钟开发一个小的应用,而且易于扩展。相关讨论:
http://www.jdon.com/jive/thread.jsp?forum=91&thread=26330

所以,不是说Java做不到快,我们更应该着重于软件设计思想的探讨。

ROR为什么受到MF推崇,实际它也是Evans DDD的实现,所以,使用Evans DDD这样领域驱动设计以后,可以让我们完全以对象方式建模 会话,表达需求,这才是根本。

关于RoR代表的动态语言(Groovy Python Ruby Smalltalk)与Java/.NET静态语言之争又是另外一个话题。

总结:ROR亮点无外乎体现下面三点:

1. 动态语言
2. Evans DDD
3. 简单的面向建模人员语言

以上三点中,后面两点需要深刻的OO思维才能发挥效率,现在很多人使用Java之所以效率不高,其实是没有形成纯正的OO思维,所以,用起OO工具不爽,同样也是RoR,所以,只有传统过程思维的人使用RoR,只能使用到RoR的动态语言特性,这个就和PHP相似了。

相关连接:
面向对象与领域建模

最近正学习RoR,惊叹于其开发效率。不过笔者以为RoR与Java的应用领域大不相同,不存在什么替代之说。
Java最重要的特点,是其广阔的集成性。各种平台、各类技术、各种设备,都可与Java溶合。这对于IT世界长久以来产生的“信息孤岛”问题大有意义。可惜国内的J2EE一开始就走偏了,关注点一直聚焦于Web。老实说,单纯的Web层面,老掉牙的ASP就已经做得很好了,更不用说近来火爆的PHP。如果Java只需干那点Web层的活儿,只要坚持JSP模式1,效率足以胜过前二者,甚至包括RoR(Java类库的丰富与成熟、JavaBean良好的封装性)。
所以Java是一个历经多年发展与考验的集大成的平台,与MS的.NET平台相对应(MS的.NET是垄断性的平台,无法与Java平台的开放性相比)。RoR是一个新兴的Web开发框架,其位置是与PHP等火爆的动态Web开发相对应的。所以Java与Ror二者目前是不可等量齐观的。
如果RoR真的存在代替Java的可能性,除非Ruby在Java广泛应用的各领域全面超过Java,这种可能性现在看来不会很大。

I completely agree with your point.of view. A lot of medium and small projects have not very many business process to be implemented. A lot of emphasises are placed on presentation tier or we say "GUI". Besides this, i think general CRUD also takes us tremendious energy and a lot of time.
In my opinion, I haven't seen any elegant, efficient, stable solution that solves these problems. Whether pattern such as MVC, new technology such as Ruby, or some thing else....
As to me, I have take a lot of time on research of these articles. And I consider that there might be two way that could be resolve these problems.
1. Technology. Smart client.
Combining with advantages of B/S and C/S enable your application more stable and more efficient.

2. Methodology of design
Thinking of container and architecture centric are two important thinking.

Acutally, Ruby on Rails and other script language have not these two charactristics. We could use them in some aspects but not most of the aspects that we might encounter in a project.
Technology of code generator is not bad. But do you expect that your projects is full of stuff that are generated by code generator that are not easy to read or not easy to maintenance.

The framework designed with thinking of container is able to provider more high level abstraction and encapsulation.

I prefer to build a mechanism that likes virtual machine. The runtime environment is based on container. Instead of code generator, we can choose various configurations describle runtime environment, define behaviors regarding what runtime environment wants to do. Configuration should be as simple as that has.
For example, instead of adding Swing components to a view directly, it's better to define the position information and events of these components in a file and build a GUI container whose responsible is parsing view file and adding them to a view.

The same thing that we can do is buiding a CRUD container. Of course, we have various CRUD container now such as hibernate, JDO and so on. It can not be denied that these containers are very good, very powerful and robust. One thing we just need to do is building a simple adapt of a CRUD container that you want to use in your project in order not to expose more detail of persitence
technology.

Back to the topic of code generator, i prefer use code generator when i met some problems that is hard to be handled except by using code generator. For example, a checking logic is a very complicated expression that should be change depending on runtime environment. It might take a lot effort if we don't use code generator. Maybe, Ruby is a good choice for this case.

In a word, the more reusable that you have, the more efficent that you could do.

各位的观点对我大有帮助,非常感谢!关于J2EE,RoR,.Net等均需要花费很大的精力去研究,我们开发产品所用到的往往是其中的一小部分,不敢轻易下结论评价熟好熟坏。学无止境。

xf从code generator代码自动生成角度谈了这个问题。这个方面MDA正在方兴未艾,但是DDD作者Evans本人并不看好这个方向。

我想再从动态语言/静态语言方面,当初Java流行前,也发生过这个两种性质的语言之争,主要是java和smalltalk,都是OO语言,smalltalk曾经一度领先,但是,确实因为静态语言可以通过编译器检查语法错误,有一个code completion,最终赢得胜利,有了Java代表的静态语言的今天,当然,那个时候.NET还没出身呢。

现在,RoR携卷静态语言又发动了新的一轮进攻,特别是2005年底时,国外不少相关讨论都涉及这个话题,那么静态语言既然能够发动二次进攻,肯定对第一次失败有了一个解决方案了,对,那就是单元测试,通过单元测试可以减少语法错误。

因为在标准的OO开发中,测试用例总是可能在先的,而且OO设计中的断言等等都是依赖单元测试生存的,所以,现在又有单元测试TDD之说。

如果我们TDD做得够好,OO设计得又够好,RoR代表的静态和java/.NET动态就不相上下了。

问题是我们国内,70%程序员还在用传统过程化思维写程序,有更多的程序员不愿意写单元测试,TDD几乎为零。

所以,试图跨越OO/DDD和TDD,一脚进入发达水平,是不可能的。切忌盲目追求新技术,要知道你有没有基础玩?

是的,我也是觉得,Java平台开发不是不能快,而是为了对以后得周期负责不能那么快.

受益匪浅

除了 C# 能动 Java 外, 没有什么能动它

完全就不是一个概念级的东西,ROR的开发效率简直就是令人恐怖,我不是高手讲不太清楚,不过大家可以去看看javaeye,这就是一群java经验者转ROR的漂亮成果,而且还在其中苦口婆心不辞劳苦的向大家介绍宣传它的好,那他们是为了什么?

昨天也有人告诉我,千万别把精力放到RoR上!
不过觉得javaeye的宣传不是没道理的。
很多时候确实觉得自己写JAVA的时候是在裸奔!