【翻译】Grails让Java程序员忘掉Rails

Tomcat5基于JK的集群（Cluster）和负载平 ... | IE7不支持localhost/127.0.0.1?

2008-01-11

从Rails迁移Grails的10个理由（译者：呵呵非常抱歉，此地址我不能访问，很遗憾。）

这里还有另外10个:

1. 视图技术还比较让人满意
2. 借助于Groovy的联合编译可以轻松的整合不同的源代码(不需要退回到C来解决性能问题 ;-)
3. 内置的 Web Flow提供了丰富的会话
4. Grails 1.0月底将至
5. IntelliJ IDE的JetGroovy 插件
6. 良好的插件体系已经集成了Java程序员所关心的GWT,DWR,JMS等

7. 忙碌的不断成长的Grails邮箱列表社区，就是揭示停滞不前最好的反例

8. 内置Spring（最基本的企业应用集成技术）

9. 服务层支持事务的自动分界和范围

10. 更多的图书将至和被一些企业组织认可

更新:

Relevance 的朋友也捐助了一些! 他们更进一步并且简洁地重新组织了我的观点，做的好！让我们摘录一些“胡言乱语”看看：

Grails 1.0 将至-
Ok，非常公平，发布的稳定版本号并不是选择Rails的的一个理由。

内置的Spring -
把此观点放到这里来确实是跟主题相差十万八千里。Rails 还没有渗透到企业呢（译者注：我并不认同），在此我们先排除。 Grails是以另一中方式渗透的，并且还在成长。因此相对于Rails的单枪匹马来说，这相当程度上归功于Spring已经帮我们解决很多企业问题。

Relevance blog 回复支持了这一观点。

忙碌的不断成长的社区 -
我并不认为Rails的社区很少，只不过它已经很稳定了，成长的空间有限了，而Grails却没有，它将来有可能变得越来越大，关注它吧！

更多图书将至 -
如题, 就算我现在不认为Grails是第二好，但也不是永远达不到

14:51
浏览 (734)
评论 (19)
分类: groovy/grails
进入论坛
发布在 Groovy on Grails 圈子
相关推荐

agile_boy 2008-02-03

我觉得Java的开发者倾向于POJO-》DB，而MS或者Delphi等应该倾向于DB->POXO

尽个人观点。

zbird 2008-02-03

没有遗留系统可用使用hibernate生成数据库。
AR是从数据库到POJO，一个是从POJO到数据库。
我比较习惯后者。

siuying 2008-02-03

隨便看看十個理由...

引用

1. GORM with hibernate/spring and jpa is much better than ActiveRecord
2. No distribution problems; runs in many production ready containers
3. Internationalization out of the box (not specifically ignored as DHH does)
4. Transactions actually work, and they include save-points.
5. Not only dynamic finders and counters, but dynamic listOrderBy
6. No green threads (although this may be fixed in Ruby 2.0, around 2010?)
7. Ability to use pessimistic locking out of the box
8. Real-live prepared statements and .withCriteria method
9. Production level test reporting with built in Mocking and Stubbing
10. Search operations are based on Lucene (with a plugin)

1. Hibernate + spring 和AR 哪個好些？這討論夠打一場仗了。我只覺得沒有遺留應用的話，AR 絕對是簡單好用得多。
2. 在 Unix 下都可以用 Rails 。如果堅持要用 Java Container ，用 JRuby on Rails
3. gettext
4. 7. 8. 暫時還未需要在乎這些問題
5. 有甚麼值得高興？
6. 為甚麼在 Rails 中需要用 thread？
9. 重要的不是 Test Report ，而是 Test 有多易寫。用 Ruby 根本不需要 Mock 和 Stub
10. Ruby 的 ferret ，或者Jruby 的Lucene

Grails 的問題在於 Groovy 本身

dunsword 2008-02-01

nihongye 写道

就是，干吗不抛弃spring,hibernate，充分利用groovy本身的语言特性构建这些东西呢。

说白了Grail是也还是过度产品。

dunsword 2008-02-01

agile_boy 写道

Arden 写道

我觉得GORM能够象Ruby on Rails一样直接拿数据库的字段来映射就好，就压根不用在model还写属性字段。

呵呵，这也是ActiveRecord跟Hibernate的ORM区别，关注点不同。

就这一点说，我个人觉得还是ActiveRecord好。

maku 2008-01-17

grails开发效率高是肯定的，但是运行效率我们只能等待了。

javachs 2008-01-17

如何有一个成功应用的案例，应该有很多人跟进的。

geszJava 2008-01-16

grails挺好,喜欢他的插件系统,在这方面rails好像比不了,期待groovy得性能提升.
rails给我得感觉太诡异,不想弄,而且效率低下,我们以前一个rss解析的性能和java写得差几十倍,搞过这方面得人应该又心得吧,所以如果要想弄rails,至少得精通perl或者python,但是有了java和groovy,这两种语言感觉好鸡肋.

agile_boy 2008-01-14

我个人的观点，扔掉Sprng和Hibernate根本就是出力不讨好的事情
重新发明一个轮子是有代价的，从起步到成熟再到被广大企业接受，这个过程至少我还不能想像

Guice从整体上来说，是根本没法跟SpringFramework比的，至少现在还不行。

nihongye 2008-01-14

就是，干吗不抛弃spring,hibernate，充分利用groovy本身的语言特性构建这些东西呢。

b051 2008-01-14

比较烦的是写一个hello world, 一发布, 好家伙, 几十兆....
最烦的是里边还藏着个spring, 我在想, 为啥G开头的不用guice?

iceskysl 2008-01-12

我们喜欢的是ruby的特性，而非仅仅是rails的方便。

agile_boy 2008-01-11

Arden 写道

我觉得GORM能够象Ruby on Rails一样直接拿数据库的字段来映射就好，就压根不用在model还写属性字段。

呵呵，这也是ActiveRecord跟Hibernate的ORM区别，关注点不同。

zaife 2008-01-11

Grails的开发效率还是比较高的，昨天小试了一下还是挺爽的

skydream 2008-01-11

Grails开发效率如果，最关心这个了...

agile_boy 2008-01-11

呵呵，翻译完有点后悔了，这是不是又在搞XXX之争么？
10 Reasons to Switch from Rails to Grails的十条看起来也比较简单，在此就不再翻译了，而且也充满了跟Rails的对比。

Arden 2008-01-11

我觉得GORM能够象Ruby on Rails一样直接拿数据库的字段来映射就好，就压根不用在model还写属性字段。

agile_boy 2008-01-11

to Vstar:thank you very much :)
其实，我个人的感觉是groovy/grails给我象java一样的亲和力。

Vstar 2008-01-11

我把那个访问不了的贴上来了，个人觉得相比Rails，Grails还是有很多优点的。今天看了一下Grails的官方网站上的插件，和Rails插件的数量差无数个数量级，但都是我想要的。

10 Reasons to Switch from Rails to Grails

After spending a few years really enjoying Rails it was difficult to bring myself to even try groovy and grails. But my latest contract forced me to look for alternatives, and I'm glad I did. Here are some reasons that you may want to switch...

1. GORM with hibernate/spring and jpa is much better than ActiveRecord
2. No distribution problems; runs in many production ready containers
3. Internationalization out of the box (not specifically ignored as DHH does)
4. Transactions actually work, and they include save-points.
5. Not only dynamic finders and counters, but dynamic listOrderBy
6. No green threads (although this may be fixed in Ruby 2.0, around 2010?)
7. Ability to use pessimistic locking out of the box
8. Real-live prepared statements and .withCriteria method
9. Production level test reporting with built in Mocking and Stubbing
10. Search operations are based on Lucene (with a plugin)

All of these don't make sense for a non-java coder. And my startup time for grails would have be much longer without my prior experience with Rails and Ruby.

One thing I thought I might be giving up was the endless list of valuable gems that make developing in Rails a real pleasure. But after re-reviewing the list of open source products from apache, java source, spring, hibernate, and even Sun (glassfish), I can't think of any gems that I will miss.