为什么java里不能把域对象和DAO合并,rails里面就可以?

service最好还是保留的好……毕竟action复杂起来，是有必要把service和action分开的，以前吃过亏……

有时候把他们合并到也挺好的，省得那么多的接口，转来转去的麻烦。

rails的controller里面一般不会有什么逻辑代码，所有的逻辑代码都是在model里面。如果是多个model协作的代码，应该再创建一个model对象来完成协作，无论如何不应该放在controller里面。

如果你把业务逻辑代码放在controller里面，这就好像在Java里面把业务逻辑放在Action里面，统统是bad smell！

这个题目太爆炸了，把java-ee和ruby-rail这对冤家又撮合到了一块，注定又是一场腥风血雨。ruby-rail的脚本、无xml、轻量等特性是java-ee的反向极端，因此，一问世就引来了java阵营的一片哗然。在java-ee台面上唱戏的老生老旦们开始人心思动，或者台下观众是一片哗然，其中不乏老戏迷和刚看了康康舞混入会场的老少爷们。楼主这个问题我个人认为是透过ruby-rail的设计，来反观java-ee领域内奢华的模式和方法，已第三只眼来观看往日的所作所为，毫无疑问，任何技术都要据实情而应用，对于复杂的应用，比如业务逻辑比较复杂，一个service需要利用多个dao来完成业务，我觉得还是要保持service层的独立性为好，反之，一个轻羽量级的应用，比如对单表操作CRUD业务即告完成，那么没有service层也无关大碍，反倒清洁干爽。我一直都认为java-ee更适合做复杂的企业应用，而ruby-rail则适合充当另一个类似php的角色，专门做互联网应用。我以前做过oa系统，后台数据库少少也百来张表，而如果是一个www网站，估计二十张表内就完全搞定，用没有service的方法肯定没有什么严重后果，效率还颇高。另外对于domain对象的问题，我觉得还是分开为好，因为在java应用中其角色太复杂，就有VO,DO,TO几种不同类型，如果都合到dao中，java的mvc根基估计该歇菜了。

认为RoR这种快捷的开发方式无法做复杂的企业应用。认为数据库表越多，Java越适应，其实这完全是自己毫无根据的臆测。

RoR的ActiveRecord并不是Martin Fowler的PoEAA里面的ActiveRecord模式，实际上是PoEAA里面的Domain Model模式。根据PoEAA的总结，Domain Model才是更加适合复杂企业应用的软件架构模式。

目前Java的框架还不能很好的实现Domain Model，使用Hibernate的方式也是贫血的Domain Model，这种方式被Martin Fowler所批评。但是在Java里面要让domain不贫血，是很困难的，技术实现上目前难度很大。

反而RoR是天然的Rich Domain Model，所以从软件架构上来讲，对于复杂软件的可重用性，业务逻辑的表达能力上，理论上RoR要超过Java。没有任何理由认为复杂企业软件，Java能够比RoR表现的更好。

Java的Service事务和rails的事务在概念上和用法都不一样，所以不能同一个标准来衡量。

robbin为什么说Java不能很好的实现DomainModel，以及RoR的业务逻辑表达能力上胜过Java？能否简单说明?

你试试看把hibernate管理的PO和spring管理的bean合并成为一个，然后你告诉我你怎么实现？

http://www.iteye.com/topic/20097

看看RoR如何简洁的表达的？

Hibernate我原先就不大喜欢用，复杂的东西，呵呵。
但是Hibernate不代表Java，所以为什么说“Java不能很好的实现DomainModel”呢？另外一点“RoR的业务逻辑表达能力上胜过Java”在该帖子中也没有看出来。
我没什么语言情节，只是想知道这个结论是如何分析出来的。

BTW:但是Ruby如此简洁，我是很喜欢的。
只可惜我还没有用过，所以还没有感受到优美。

持久化不属于领域层的范围，属基础层，如果把持久化这种琐碎的细节都绑在Domain对象中，Domain Model就失去了意义，隔离出一个干净精练的Domain层会比较好，那里是软件的核心。
Java这样清晰而严谨的语言是实现Domain Model的极佳选择，很容易理解和交流，把Domain Model和Hibernate、Spring联系到一起应该是过于放大了Domain Model的职责范围。
Domain Model不能太胖，也不能太瘦，能够完整地描述核心业务功能就刚刚好，现在流行的层次结构中的Entity只是简单的属性集合，把所有的业务功能交给Service，这就制造了一个瘦Domain Model。Domain Model里的Entity应该具有职责范围内的业务功能，而且Domain Model中的对象不止是Entity一种，还包括Domain Service，比如需要多个Domain对象合作完成的业务功能不方便放在哪个Domain对象中，就需要单独的Domain Service，当然，分清Domain层Service和应用层的Service是有一定难度的。