我是做了 java 之后转做 ruby 的，不过我只做了 java 2,3 个月而已，我之前做的是 java 的网游服务器，hibernate 太难用了，从数据库生成类代码有些地方还要手动改，好烦的 (也许是我们没用对，我 java 仅仅是学徒级别),JPA 没用过，不过这些 ORM 都没法和 active_record 比，ruby 语言在语法简洁和功能上甩 java 几条街，scala 倒是可以和 ruby 竞争。
推荐你看下下面这个文章 http://david.heinemeierhansson.com/2012/rails-is-omakase.html

Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere.

开发流程你可以去看 web 敏捷开发第四版，据说国内翻译的不好，还是看英文吧...

根据你在http://ruby-china.org/topics/8347里问题

个人感觉你把实体的具体化了到 java 的 Entity 上，其实做 rails 开发，或者说其他开发都是以需求分析，设计为先的，在设计时你说的实体并不需要以某种特定技术作为背景，可以仅仅只是业务模型或者领域模型。然后用你熟悉的任何工具来描述，比如 UML。

在你用 java 和 hibernate 时，是通注解和属性的定义来生成的数据库表，实际上 hibernate 也是双向的，也可以通过数据库表生成 Entity。

在 ruby 和 rails 里，更常用的是通过 migration 来管理数据库表，rails 会根据数据库表的字段来给 model 加上属性，不需要在 model 去写属性，更加不用一大堆 getter，setter。

所以你的转换是的是从把业务模型 (实体)具化成 java 的 Entity 转换到把业务模型 (实体)具化成 active_record 的 model(通过 migration)

#2 楼 @kenshin54 说的好。

Rails 是 BDD 的吧，想好 story，然后再来写就行了。Hibernate 挺好用的，跟 rails 的 activerecord 各有千秋吧。从我自己的角度来看，还是更喜欢 active record

做 rails 基本是两三下就把业务搞定了，然后大量的精力在调整 UI 上...

#1 楼 @sailtsao 首先，我可以确定你没有学好 hibernate。第二，ORM 只是一个概念：能把对象，对象间的关系映射到数据库。只不过，我在有些时候，在实体里看不到属性，但是实体相应的表中倒是有那个字段，感觉有点奇怪罢了。

#2 楼 @kenshin54 嗯，我大概明白你的意思。 一、我是以对象为中心的开发，而不是数据库表，或者数据。所以，hibernate 的通过表生成对象的功能，我几乎忘了有这个功能。所以，一开始，我都只是写对象，不需要写数据库操作，但使用 rails，我看到的视频一开始就会说怎么操作数据库。 二、我说的实体不只有 getter ,setter。还包括了业务方法，如 Comment 类中，会有 save 方法。在国内，很多人写的 Entity 都只是 getter，setter。 三、我觉得：直正的 ORM 是，在我写完类的时候，类对应的数据库中的表也相当于建好了。

ruby 的业务逻辑层有点薄弱。现在主要是跟 ORM 耦合在一起。

#7 楼 @chucai 第一，ORM 只是一个概念。 第二，我个人认为业务逻辑更应该放在 Model 中，而 application 类只不过是一个对外的门面。所以，Rails 中，application 类才会很薄。

#8 楼 @zacker330 是的，对于小项目，这是可以满足的。但当你的业务 特别复杂，这就有点不合适了。这个时候，一般会使用 concern 将业务逻辑剥离出去。或者参考 java，单独写一个业务逻辑层。

#9 楼 @chucai 嗯。 我不知道你说的小项目是多小。我也不确定8楼我是否说得够明白。但，我知道业务放在 model 中更内聚，你的依赖才可以更小化。 你说的对于小项目，可以满足，我可不可以理解为大项目的时候，model 会变得很庞大。如果我理解的是对的，那么我说你的 model 没有建模好。因为你的没有把关注点分离好，你将太多的东西，交给一个类去做了。

其实业务和技术都是相当重要的，没有先后之分，但有主次之分。 但具体操作时，就像线程一样，总是来回互相切换的。面对一个任务，我们先要分析分析具体是做什么，在分析业务的过程当中，我们一定会去想这个功能具体要用到哪些技术，是否在能里范围之内，如果不在能力范围之类，要估算出掌握该项技术需要的时间，所有的一切几乎是并行执行的。

对于新人来说，技术为主，有工作能力的人来说，业务为主

Rails 相当于你在 Java 领域的第一步，理清业务。 由于技术细节都帮你搞定了，所以就没有第二步了。

以前常纠结 Rails 的开发流程，是从数据库开始呢，还是从 UI 开始。现在我比较赞同的流程是先设计用户故事，然后写 cucumber，或者集成测试代码，确定需要的 controller 和 action，然后在写 controller 的测试，最后 model 和数据库设计。这样，数据库的设计只是其中非常小的部分。其中有一个值得注意的地方，一定要把握好测试的粒度和 mock 对象。这样流程才会比较通畅。实际工作中，实现这个流程比较困难。

@zacker330 我咋觉得 ORM 是把数据库映射到实体对象的呢，跟你说的感觉反过来。数据库也只是对象持久化的东东

一直以来，rails 的投入总是在最后期编码阶段，大部分会是业务的分析，然后业务的可行性（这里就要带各种开发的经验，这里会否掉很多业务需求，如果你能说服客户，怎么说看你能耐，要做可以，时间和钱），再然后对象封装（这里就建类、关系和迁移），再再然后就是 UI 和 model 还有 action 了。。。