读hibernate in action 和 PEAA 后发现感到的迷惑

to frankensteinlin:
这贴子确实是你发过的贴子,只因为这个问题我还有很多不明之处,希望另外开帖子讨论.目的都是为了更好的解决这个问题.
至于你的名号没有挂上,是我疏忽了.

严格的分层应该是这样子的：

Business Object - > DAO Interface - > DAO Implements - > Domain Object

目前我们项目的做法是:
BusinessFacade -> BusinessLogicService --> Persistent(OR Mapping).

没有使用到域层.持久层用Torque实现.层间数据传送使用VO.

把1和4方法放在domain object违反了“单一责任原则”。持久层和业务层的变化都会影响你的Order。

持久层责任由dao接口定义,并由其实现负责,domain object调用它,并没有掺和dao的实现,不能说违背了..原则.

在这个use case里,实现需要持久化,需要事务服务.可以让OrderService 做为事务的边界.也就想当于tx = xx.beginTransaction()和tx.commit这样的代码用一个removeItem(Order order,String removeItemName)来表示了.假如更进一步,
这个服务还需要发邮件,需要文件系统的服务呢,用IOC给OrderService置入这些服务显得很好,对于使用着来说,只要取得这样一个组件就ok了.

但是要是逻辑在Order里,那么要把dao,事务,邮件服务,文件系统服务这些都置入Order里,但Order对使用者来说,可能是从数据库load,或new出来的.
1.Order order = new Order();
2.ComponentService.injectServiceAndMakeTransactionSupport(order);
3.order.removeItem(String removeItemName);
第2句看起来很不爽(这个动作在哪里做呢?!!很严重的问题),可是业务接口看起来又很爽.
或是使用静态aop,编译一把,2这句就不要了.爽,可是事情被弄得很复杂,有点吐血得冲动!

问题是：domain object 很可能自己不能够完成所有的任务！中间有可能要访问数据库阿，这样中间好要调用dao 似乎很不方便阿。 robbin的意思是 用户的接口在bo上面 这样的话，会不会造成贫血的domain object？ bo 过胖？

domain object 应该表达的是自身的属性和与其他domain object的关联，也就是在domain object层表达清楚整个实体的对象图就足够丰富了，不应该再加入各种业务相关的操作。

那么 domain object 和一般的数据集合的区别就不太大了，我的理解它至少要有在关联对象间的导航功能。可是如果它连访问数据库的功能都没有，如何导航呢？ order--〉orderItem-->productInfo-->所有的附件__>产品价格表:
那么order 里面应不应该有个计算总价的功能呢？是把它放到bo里面？ 那么order基本就是和数据库里面的记录差不多了，和rich domain 哦bject 的目标差的太远了点吧？

计算总价不应该放在Order对象里面，这是很显然的事情。Order对象表达的是单个订单这样一个事物，总价是和所有的订单相关联的属性，它怎么能够往Order里面放呢？再说这个所有的订单，什么叫做所有的订单，肯定是有某种条件限制的Order对象集合，那么这种条件限制的过滤操作又怎么能够往Order里面放呢？计算某个过滤条件下面的Order对象集合的总价是毫无疑问要放在BO里面的！

domain object和数据集合的区别不是不大，而是非常非常大，domain object形成了一个对象关系图，object之间有聚合关联，依赖关联，组合关联，继承关联，以及各种各样的对象关联，正是有了这些丰富的对象关系的强大表达能力，才使得Mapping之后的domain object变得如此强大，能够尽量近似的表达具体的业务的复杂关系和业务实体，能够最大限度的提高软件系统的灵活性和可维护性。而关系数据表达，他是一个扁平的二维表格的数据结构，它无法描述很多业务实体之间的复杂的关系，换句话说就是二维表格不具备业务实体的自描述能力，而domain object具备了业务实体的自描述能力。

不说了，这问题让我回答得很沮丧，对象模型和关系模型的究竟有何不同都没有很明确的概念，建议大家先讨论对象的基本模型再说吧。

robbin，下面这个情况应该如何处理？

DomainObject： folder 1 ---- * file
（这里仅仅是用Folder和File做个比喻，因为是计算机上最常见的东西，容易理解）
业务限制： file.name 在 folder 中唯一。

这条业务限制至少需要在3个地方进行控制：

1）建立file时。
2）修改file.name时。
3）在folder间移动file时。

方法1：如果将这些操作放在BO里，那么势必会有如下操作：
FileManager.createFile(folder, fileName);
FileManager.changeFileName(fileName);
FileManager.moveFile(folder);

-------这么做有个问题，如果File里面有许多这样的字段，并且都有不同的业务限制的话，那么需要在FileManager里面针对每一个这样的字段添加代理方法，如果这种东西很多的话，最后FileManager是不是就变成了File的马甲（包含业务规则的Delegate）？？？

方法2：如果将这些操作放在DomainObject里，会有如下操作：
folder.createFile(fileName)
{ 
    new File(this, fileName);
};
file.setName(fileName);
file.setFolder(folder);

-------这样单纯从OO上看，是把File的业务规则放在了File里面，应该是比较清晰合理的。
但是实际中这样的话，DomainObject就不可避免的需要使用DAO啊。

首先来说，文件系统和数据库两回事，没有什么类比关系，这个例子也举得不好，何况你的DAO设计的也不合理。



1)

File file = new File();;
file.setFolder(folder);;
file.setName(name);;
file.set.....;

fileDao.addFile(file);;

2)

file.setName(newFileName);;

fileDao.updateFile(file);;

3)

file.setFolder(newFolder);;

fileDao.updateFile(file);;