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

yours:

orderDao = factoryA.getOrderDao();......  // 获取远程服务
orderItems = orderDao.getOrderItems(order);;

mine

public class Order { 
...... 
    public List getOrderItems(); { 
          orderDao = factoryA.getOrderDao();......  // 获取远程服务
          return orderDao.getOrderItems(order);;     } 
} 
如果我要用ioc容器的话 你也要用阿，我要远程 lookup,你难道就不需要了么？大家不是一样的么？都依赖于一个工厂。而且工厂的复杂程度也应该是一样的阿。只不过你在bo里构造工厂 我再domain 哦bject 里面构造工厂。

好了，我明白你们的意思了，你们的意思其实是：



我的意思是：



不过我这里这个domain object实际上也是POJO的，所以可以直接做为DTO在业务层和Web层使用。

其实你们那个模型就是传统的EntityBean采用的模型，CMP/BMP+Hibernate就是这种样子的。

我没有看过Martin大叔的书，所以不知道人家大牛怎么讲，我只根据自己的经验来谈(曾经有人攻击我说我没有自己的观点，都是抄大牛的观点，这是对我的褒奖呵呵)。

Entity Bean这种模型其实有很多缺陷的，这种模型本质上强调All-in-one，它既要表达实体类模型，又要代理对实体类的持久化操作，又要必须处理隐式的资源管理和事物管理，太多的职责压在domain object上面了，你没有办法让domain object变得 POJO起来了，结果就是必须给domain object适配一个庞大的管理容器，并且这种情况下你的domain object也无法作为业务层的DTO出现，你还必须另外写DTO，并且编写DTO和domain object的双向转换，呵呵。

另外好像DomainObject不需要远程取得dao，因为DomainObject只是在Server的容器内运行，Client对DomainObject的使用都是通过一个薄的ServiceLayer（SLSB）吧。
GUIClient --> ServiceLayer --> DomainObject --> Dao --> ORM -->Database
Client与ServiceLayer之间使用DTO/VO.

哎，这个问题一直是争论的焦点。

双向依赖的现象的确存在但是想想，他dao命名成为orderdao是不是一种隐性依赖呢？dao interface 对于domian object 依赖 其实是很弱的基本上就是一个类型的依赖，（比如返回一个order 对象 ，传入一个product 对象）如果这些基本的业务对象名称改变的话，估计动的东西就很多了，反观你的的单向依赖是有代价的 orderBO -->orderDao --Order (其实orderbo 也是依赖于 order的) 他们三者之间的互动性并不比我的方案少。

说了半天，你怎么还不明白，我的方案中，不管我是IoC也好，是工厂也好，还是直接new也好，还是JNDI也好，这全部都是客户端自己的事情，和domain object毫无关系！domain object不关心也不需要知道客户端它怎么折腾。即使换了n种框架，n种Dao，我domain object自岿然不动。而在我的模型中，domain object是可以直接做为业务层和Web层的DTO的，所以domain object的稳定意味着整个应用程序结构的稳定。

而你的方案中，你的domain object是依赖于具体的Dao创建环境的，你的domain object必须关注Dao是如何创建的，并且domain object的行为是受环境影响的。

你能告诉我你的domain object和传统的Entity Bean有何本质区别吗？ 嘿嘿，你自己研究一下吧，会发现他们本质就是一回事。

没有话讲了，也不准备再讲下去了，反正我该讲清楚的地方都讲清楚了，你硬要说你那种Rich domain object(在我看就是换汤不换药的Entity Bean)就是依赖小，就是变动小，我也没有办法。

其实这个问题我也想了很久了：bo 与 domain object 的关系，写的久了，发现真的有些重复，domain object基本上就像一个数据库的映射+对对象关系维护。bo的作用就像为了（管理trasaction + 对数据的运算）其实所有数据 domain object 都有了！为什么它不能自己作业务操作呢？问题就在transaction(我那个时候孤陋寡闻，不知道spring 和 openSessionperreqest 的技术。) ，现在看来transaction的问题解决了，又有了hibernate 使得在domain object 中导航相对比较容易的ormapping，是否可以省略掉bo？让操作和数据由一个类来管理呢？（原先的bo似乎就是拿了别人的数据+dao的操作，把自己伪装成对象）赫赫 好像过了点。

我不知道你说的客户是什么 是bo吧（我想不会是真的客户端）你的bo总是要知道dao 是怎样创建的吧？你发布的时候你的bo不是很和你的ado domain 哦bject 一同发布的？同样存在lookup的问题啊，只是问题发生的地方不一样为什么，职责不同。 还有个问题：你的bo不需要稳定？ 估计你整真的业务核心在bo吧，它才是最需要稳定的，我的domain object的职能其实和你的bo是一样的！

你的domain object能做些什么。就是一个数据的和一个关系维护的纪录集