有关领域对象

对那些传递值的DTO一向没有好感，在ejb1里面用是因为没有办法，现在能避免就应该避免，这样的类完全不是个对象，当然就更不是业务对象了，楼主的文不对题。

楼主还是去看看 《企业应用架构模式》，
按照该书中的分类法， 楼主提的做法可能属于
“事务脚本(Transaction Script)”
,而不属于"领域模型(Domain Model)"。

我想大家都没用Domain Model吧。

这样讨论没什么很大的意义吧，实际工作中你是怎么做的呢？我实际工作中就是我之前说的说法去做的，觉得也挺好的，而且也可以保持层次的界限清楚

建议可以看看Hibernate in action，里面对Domain Model比较清晰的进行了阐述，并且举了实际的例子说明Domain Model的设计

这是Hibernate in action的一段话，看看：

DO只是负责完成业务模型而已

在试图用Domain Model的情况下,发现缺少OO的分析方法,
于是去试图啃 < 分析模式>和<color Uml>，看了点皮毛就到
实际项目里去用了。至于效果，要等项目结束才知道。

to: o6z   老兄该讲color uml了吧，已经等了好久了。

如果没有关系数据库，那么存储也算是业务逻辑的一部分，如果没有ORM，那么维护把对象之间关系映射到RDBMS也算是业务逻辑的一部分，当然我们真正所谓的业务逻辑是没办法简单地用ER关系(UML对象关系)表示的逻辑关系，举个简单的例子

把一个学生加入到一个班级是不是业务逻辑？

如果只是简单地维护一个学生和班级之间的n:1关系，然后持久到关系数据库，那这个只需要一个collection和hibernate的持久机制即可，我们不需要特别的业务逻辑，只需要transaction script即可

查询一个班级里面的所有学生也是同样道理

如果要计算某一个产品的价格，我们需要从产品BOM结构计算出总成本，加上各种价格策略，最后计算出一个结果，那么这个价格没办法通过简单地数据库操作直接得到，这个时候我们认为它具有丰富的业务逻辑，需要通过相关对象(BOM)的协作得到结果。

当然这种关系也可以通过Transaction script和存储过程或者是复杂的SQL操作得到，但是用OO的领域对象实现，我们就可以自由的运用各种设计和分析模式以及其他技术，例如知识层、规则引擎或者策略模式，从而使得这个价格计算可扩展、易维护，这就是领域模型的优势所在。

领域对象模型指的不仅仅是一个包含丰富行为和数据的对象，更多的是指多个相互协作的对象组成的模型。
在这个意义上来说：
实现相对独立的对象和底层entity协作成一个领域对象模型 比 将各种行为划入entity，让entity组成领域对象模型要好得多！
如果直接将POJO entity对象层次扩展成领域模型，这显然不可取，虽然省却很多逻辑，代码和类。但是却使得整个应用极度臃肿，难于扩展。
POJO作为data object，确实不应该融入更多的业务逻辑。

很同意哦...........呵呵，主要是在我们现在的系统中基本碰不到这种需求，觉得Domain Model适合的场合是持久层部分业务逻辑比较复杂的系统，不过觉得即使业务逻辑不复杂时也可以用Domain Model，因为Domain Model的另外一个优点在于简化了Service层，使得Service层保持了其层次功能的清晰，在业务逻辑不复杂的情况下我觉得在Hibernate中PO就基本可以起到DO的作用了

从 Transaction Script 到 Domain Model 的迁移，目前还刚刚起步。我完全相信 Domain Model 是一种更好的设计方法。但是现在对于大部分公司来说，他们以前的开发方式可能完全是基于 Transaction Script 的（不完全是 OO 的），他们解决了大量的复杂问题，遗留下来大量可重用的代码（这些代码虽然不完全是 OO 的，但是确实可以拿来就用，就象很多 C 库函数一样）。他们利用这些可重用的代码达到了很高的开发效率。从成本上考虑，他们不可能把以前的成果完全推倒重来，而只能在一些新的规模和风险都比较小项目中尝试这些新的设计方法。对于以前的那些遗产代码进行重构或者重新设计，需要比较长的时间，有些公司可能难以承受这样的成本而把这件工作放在靠后的位置。

至于从 Software for Use 的角度，这两种设计方法我相信都可以达到很好的可用度，对于用户来说区别是不大的。所以我的预计是它们将长期并存，这个就和我预计数据建模和对象建模的设计方法将长期并存一样。

从作为一个系统架构师的职业生涯发展的角度，AOP、Domain Model 是我们必须关注并且加以深入学习的两个领域。potian、gigix 等先行者可以带给我们很多新的营养。