关于Domain Object中业务逻辑的事务处理的疑问？

那你还用Hibernate干嘛
直接用Spring的JDBC模板不是更方便，O/R mapping变成R/R mapping

http://flyingbug.blogdriver.com/flyingbug/403118.html

其实楼上各位的冲突就是以领域建模作为类结构设计的基础还是以概念建模作为类结构设计的基础.
     不过我是反对以领域建模作为类结构设计的,我列举一下它会存在的问题吧:
1.采用这样的方式,就会出现,类结构的关系复杂化,比如一个类除了本身的通用(所谓的通用又是怎么样的一个范围概念,没有人清楚)外的操作在其他类来处理,是怎么个处理法呢?是依靠于另外的一个领域对象类,还是单独的业务逻辑处理类?如果是前者,自然就造成了领域对象的耦合,如果是后者,起码也就违背了面向对象的基本法则,破坏了封装, 这种操作方式,只是适合于比较单独的领域对象.
2.采用这样的设计方式究竟是在哪个层次呢? 业务层?数据持久层?还是表示层,或者每个层都存在.如果是单独在某个层,那么在其他层都是需要领域对象的数据的,那该传什么?领域对象么?如果在所有层的话,而每层的逻辑操作也不尽相同.如果将这样的类(可以说是粗粒度)传入到其他层, 那调用逻辑操作会是什么概念呢?(简单地讲,在表示层调用Account对象的存入金额,就真的代码存入了么?), 这样的设计方式,怎么都脱离不了, 业务逻辑的真实实现(不是简单的+-*/的)都必须抽离的,那么领域对象中封装的操作又有什么意义呢?
3.另外还有很多问题, 比如事务也自然是了, 谁说"通用"(不知道这个词的概念究竟是什么意思)的业务逻辑操作就不需要事务了?难道一个事务就不能跨越多个基本的操作么?简单地举例, 从银行账户取出钱投入股市(也就是所谓的银券通了),因为是异构的系统,所以不要指望有基本的业务逻辑,原理就是基本的取款,然后再存入证券帐号,通过一个事务来封装处理. 两者都是所谓通用操作,难道就可以不用事务封装?
     我建议楼主可以看看关于建模的书,把领域建模(其实也叫业务建模),概念建模,数据建模,对象建模 的概念,作用,范围理解清楚.

呵呵，先谢谢你这么长的回复 ：）

关于你的第三点，不知道你从哪里看出的“通用业务逻辑不需要事务处理”？不用事务处理的话，那银行，证券干脆关门算了 ：），我只是想寻找一种比较好的事务处理方法，不过我又翻了<企业应用架构模式>中的关于Service Layer的介绍那个章节，采用了实现方法中的第二种方法“操作脚本”很好的解决了我上面遇到的问题

用HIBERNATE是因为不想写好多delete、update、insert的SQL语句。
不采用关联关系就可以让一个对象贯穿整个系统的所有层次，不论我的service是在web server还是在local ejb server或remote ejb server。

1.实际上我们面对是在三种操作CRUD，domain logic，application logic。(将business logic分为domain logic和application logic.)

2.这三种操作都在service layer里提供接口或实现，分别将CRUD委托给dao，将domain logic委托给domain model，而application logic则在service layer里实现。这样service layer起到一个facade的作用，易于web层的调用 。

3.transaction的声明就统一在service layer上。

4.我的问题是：这样一来会不会显示service layer有些凌乱？或者有什么不好？

请诸位给出意见！

en,使用Hibernate对单表确实是有这个好处
但如果多表关联操作的话我想你的代码量比使用JDBC模板要多一些

另外让一个对象贯穿所有层次跟你后面那句话好像不是一个意思吧？

我现在的解决方法和你的方法一样，这也是PoEAA 中 Service Layer章节中给出的一种实现，我觉得没什么凌乱的地方，而且逻辑很清晰。

我不想做DTO，不想考虑HIBERNATE的懒加载问题，所以就这么干了。多表关联操作跟JDBC差不多，只是用HQL。

1.如果坚持分层的观点，业务对象就不该调用控制对象的方法，更别说服务层的方法。
一次事务中多业务对象的操作可以封装在一个控制对象中，甚至在维护单个业务对象时我也这么干。然后这些控制对象将在服务层被调用。
服务层的结构一般如下：

public class AccountServiceImpl extends ServiceFacade
      implements AccountService
{
  ....
  public transfer(String from, String to, int amount);
  {
    try
    {
        initSession();;
        Act act = new TransferAct(from, to, amount);;
        act.run();;
        commit();;
       catch(...); 
    {
       throw exceptionPostProcess(e);;
    }
  }
 ...
}

public class TransferAct extends Act
{
...
   public override void doRun();
  {
     fromAccount.withdraw(amount);;
     toAccount.deposit(amount);;
  }
...
}

public class Act
{
...
   public void run();
   {
      doPreProcess();;
      doRun();;
      doPostProcess();;
   }
...
}

2.我不赞同Account需要AccountService来管理的处理方法。
使用AccountService把Account当作纯粹的数据对象来处理，同面向过程的方法没有多大区别。

感觉楼主得Account中得transfer方法不应该放置到domain model中。从职责得角度来看，一个Account对象怎么能具备一个transfer得行为呢？