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

如果不需要OO，不需要domain model的话，我用Java，可以区区一行代码搞定，无非多写几个分号而已。

ruby火不火和我一点关系都没有，ruby火了对我有什么好处？那大家都会ruby了，我还有什么可以炫耀的资本？ 我就希望ruby不火，你们都别用，就我一个人用ruby做JavaEye网站，那我多开心阿，成天拿ruby在你们炫耀，多爽。

jkit的“我们”指的是哪里？

呵呵，我倒是觉得“RoR那种Service对象，DAO对象，domain对象三位一体”从某种角度上看是种设计的倒退，Service和DAO合并我起初不太习惯，现在逐渐接受，但依然不太喜欢Service直接继承泛型BaseDao（虽然我们目前也偷懒正在这样做），我觉得用聚合相对会更顺一些，毕竟继承是“is-a”的关系。

个人觉得Domain model应该是游离于技术分层之外的东西，正如你在 http://www.iteye.com/topic/11712 中所说的“Item不能对ItemDao产生依赖”，同样的，它不能对Service产生依赖。

Domain Model应该算是新瓶装旧酒了，它会被再次翻出来是因为Java界终于有人说出了大家都知道的真理“技术架构年年更新，业务知识十年长青”，举个简单的例子，Group(组织) - Role(角色) - User(人员)，Product(产品) - Order(订单) - Customer(客户)，近十年来，就我所知道的CRM的Domain Model，财务预算的Domain Model，都没有发生什么大的变化，不管你是用Java做、还是Delphi做、或是RoR做，所以我始终觉得Domain Model是语言无关性的，一个语言无关性的东西怎么可以跟DAO这种技术术语混合在一起？Delphi里的持久化跟Java的DAO完全就不是一回事，难道流行一种语言就重新积累一次领域知识？

前两天在denver参加公司的away day，拿这个问题问了下老马。他不置可否……

谈一下个人的认识：
Java的企业级应用复杂的原因很大程度上是分层过多所造成的，根源在于各对技术环节极端的解耦。Domain Model与DAO分开，意味着领域模型与数据存储及数据访问方式解耦。这样的话，我们可以在保持领域模型相对稳定的情况下，采用不同的数据访问方式，不论是大多数基于关系数据库的，或是XML数据，以至于未来的面向关系数据库。而dao的操作，即可采用jdbc，也可采用Hibernate、ibatic或是JDO，以至于未来的任何访问技术。这样的话，当数据存储方式发生变化（需求或技术潮流变化）、或是采用的数据访问技术（性能要求或团队技术）变化时，领域模型可以大体上保持稳定。而换这正是“稳定压倒一切”的企业级应用最为关心的事情。
虽然说我们眼前在大多数情况下用的是关系数据库+hibernate，完全可以省略掉分层，像RoR那样明确地将DB+AR绑在一起以减少复杂性，提高开发效率。但未来技术环境变化了之后，我们还能不能保住领域模型。在这个问题上，J2EE是宁可复杂也要解耦，而RoR则是宁可耦合也要快捷。重申一下，此处的“解耦”、“耦合”是指技术环节上的，不是设计和编码上的。

对此，我们正好可以因需取用。这也就是我目前所主张的在DB+Web领域使用RoR利用其快捷，而真正的企业级应用采用J2EE照顾其稳定的一个重要原因。

对于service分层的必要性和好处，本人没有太多的认识，大家可补充讨论。

至于表现层的解耦，本人认为在企业级应用中是至关重要的。

其实这么多年了，软件技术不断变化，变化最快、最多、最激烈的还是在表现层。最初的字符界面，到图形桌面、Web、Ajax，到现在热炒的RIA。至于以后，肯定还是要不断变化。如果锁定表现层，对于企业级应用是非常可怕的事情。像过去用VB、PB、Delphi这些技术环节紧耦合的工具做出来的应用，当初做得是够快了，可当用户界面转向后，大多数都被无情地淘汰。这对于企业的业务实在是一场恶梦。而且很多业务应用对时效性要求很高，以桌面图形为表现层的技术是必须的。
所以对于稳定性要求高的企业业务系统，本人认为一定要把表现层分离出来。

J2EE一开始就是以此为基本架构的，JSP、applet为web表现，swing为桌面，甚至现在很多人用winform也没有什么问题。就算以后用RIA，甚至其它未来的表现层技术，应当也不成大的问题。当初开发（即使用Spring）的时候，那么多分层，复杂得痛苦无比，但企业的领域模型和业务逻辑保持了长久的稳定和重用。这种代价对于稳定至上的企业级应用最终还是有回报的。

至于快速变化的互联网领域，“计划不如变化”，快速应变的要求远甚于稳定性。Web将长时间作为表现层，锁定Web无疑是明智的。采用RoR（对于习惯了OOP、ORM、MVC的Java程序员），或是PHP（对于习惯过程式编码的程序员）不失为上佳之选。

我认为ROR恰好提供了一面光鲜镜子，用来比较目前java实现DomainModel中，那些是核心必须保持的，某些场合下，哪些是可以合并的，哪些是可选的。

另外，无论是ROR和Java，我认为都没有很好的解决OO承诺的“封装”问题，或者说解决得不够彻底。

Robbin:

如果不需要OO，不需要domain model的话，我用Java，可以区区一行代码搞定，无非多写几个分号而已。

ruby火不火和我一点关系都没有，ruby火了对我有什么好处？那大家都会ruby了，我还有什么可以炫耀的资本？ 我就希望ruby不火，你们都别用，就我一个人用ruby做JavaEye网站，那我多开心阿，成天拿ruby在你们炫耀，多爽。"


我觉得讨论问题应该是平等的，真诚的，不要动不动就上纲上线，或是摆出技术权威的样子。也许Robbin在某些方面确实有过人之处。但这不是你说教的资本。

同是强类型语言，一个是动态的，一个是静态的，这种不同的风格也就产生了很多限制。
Ruby中类是对象的原型，有实例变量等不同的概念，而且Ruby对元编程的充分支持让它非常适合描述领域模型（这是一种描述，而非“封装”，因为原信息本身就应该是描述），Java中的Class则和Ruby中的类意义不同，更多表示的是封装。Java中用反射做元编程相当别扭（Java不是单根继承的面向对象抽象，比如倒霉的原始类型和数组，它们都需要单独判断），对领域模型的描述带来了一些麻烦。而持久化逻辑的注入在Java中就更尴尬了，要用动态代理、或者静态增强类似的AOP方式来做，并且由于数据访问的对象的封装从语义上不属于领域模型本身，所以对它的注入就更加尴尬，如果真的像AR这样封装技术上可以实现（相当复杂），且语义上你写的那些东西也有点身份不明。Ruby中通过模块mixin动态的增强领域模型，这很好体现了领域模型应该描述的内容，让领域模型的逻辑真的透明化。所以语言的理念确实影响了AR模式在Java中的实现。
此处说的比较乱，推荐读读Bruce Tate的《Beyond Java》会有更清晰的想法。