dao/service/action 这样的分层结构和数量众多的级联删除的矛盾

1.最近做了一个模块，有15个左右的数据表，表和表之间一共有10个左右的外键关联。最多的一个表和其他4个表有外键关联。

2.编码实现的时候，采用了dao/service/action这样的分层结构。
  针对每个数据库表生成了一个对应的POJO。

3.在做数据删除的时候，很多时候都要作级联删除。
  每次级联删除的时候，就依次调用几个dao来完成。

  假设有如下的级联删除关系，删除A的时候，需要同时删除B，C，D。
  A -> B -> C -> D

  补充一下，删除C的时候，要级联删除D；删除B的时候，要级联删除C；删除A的时候要级联删除B。

  我的做法是对应A，B，C，D都有一个service类，
  在这个类里面有一个delete的方法。

  先在 D_Service 类里面实现删除 D 的功能，
  然后在 C_Service 里面调用 D_Service 类的方法来级联删除 D。
  依此类推。

  这样的做法我存在疑问：按dao/service的分层策略，一直以来我的看法是同一层的public接口最好不要有相互调用的关系。一个不好的地方就是可能导致各个service之间循环依赖。目前来说，还没有出现，但是总觉得接下来如果数据之间的关系进一步复杂，有可能真的导致循环依赖。（会不会有点杞人忧天？或者说如果造成了循环依赖，那是数据设计做的不好。）

  现在准备进行一次重构，就是在service层增加一个ServiceUtils类，
  这个类是对于其他package是不可见的，只给其他的service类调用。
  这个类里面注入所有的dao，专门做级联删除功能。
  如果这样做了之后，那么所有public的service之间就没有调用关系了，
  所有的public service都只是调用 ServiceUtils类。

  对于这种做法的疑问：ServiceUtils类纯粹就是类似C编程语言里面的全局函数的一个集合。

  不知道大家是否遇到过这样的问题，又是怎么解决的？

4.现在用的数据库访问框架是ibatis。上面这个问题在hibernate中好像是已经被很好地解决了。

把A,B,C,D封装为一个Service好了.既然B,C,D是依赖A而存在的.
单独删除B是否会产生问题?
举个例子OrderService,OrderItemService.
比如OrderItemService.delete(item)显然不行.应该使用OrderService.deleteItem(item),所以OrderItemService在这里不应该存在.

如果你只是要update OrderItem呢，你总不能直接去update Order 吧，所以我认为OrderItemService 还是需要的，不过可以没有deleteItem这个方法而已

 假设有如下的级联删除关系，删除A的时候，需要同时删除B，C，D。
A -> B -> C -> D

补充一下，删除C的时候，要级联删除D；删除B的时候，要级联删除C；删除A的时候要级联删除B。

那在这种情况下，B，C，D对应的Service类都不用存在delete方法，只在A对应的Service类里面存在delete方法吗？

如果是这样，有如下的疑问：
1.要删除D的时候，怎么删除呢？在A对应的Service类里面，存在deleteD，deleteC，deleteB，deleteA这样的四个方法？
2.这里举的例子是一个比较简单的。复杂一点，假设级联删除关系如下

     A 
     ||
     \/
A1 -> B -> C -> D

就是说，假如还有一个A1数据，对应也要级联删除B，那么这时候，又怎么安排deleteB，deleteC，deleteD的方法呢？

这个问题我也是感到很困扰的,
比如order和item,删除order肯定要删除item,
但是又不能在order里面关联上item,这样对于order来说多了很大的负担.
所以一开始我是在action里面分别的进行处理,但是这样做事务处理成了问题,
后面没办法之下我只好在orderservice里面通过获取itemservice来调用deleteitem的方法,这样做总感觉打乱了service/dao这种结构.

http://www.theserverside.com/news/thread.tss?thread_id=23705

Opinion: One big Service class or several small classes?
同样问题的讨论.