hibernate中的关系处理心得交流

以前使用hibernate的时候关系都是根据业务来处理的，也就是对象间的关系没有设置，仅仅设置一个ID外键来做关联，感觉对象的管理蛮方便的，研究了领域驱动设计很长时间了。最近一个项目使用了hibernate的关系，但是怎么处理起来都觉得别扭，举个例子：
用户和用户组以及角色三个实体:即：User,UserGroup,Role他们的关系为User和UserGroup为many-to-many,UserGroup和Role为many-to-many,关系都为双向的。
开始的整体结构为：
dao层：封装简单的dao的操作，没有处理关联关系
service层：处理业务逻辑，涉及到关系的处理，调用dao层
别扭得地方：
1.如果在UserGroup对User上设置了级联插入关系:
那么当插入UserGroup的时候，UserGroup中的User集合也会插入，但是这个时候如果有业务上的要求，用户名必须唯一，级联插入的时候抛异常，的确这个情况我们还是可以处理的，但是必须知道会抛什么异常，然后catch住了之后，抛出自己的业务异常，感觉处理起来不是很流畅，如果在User设置对UserGroup级联插入，情况可能更复杂，比如UserGroup对Role也设置了级联插入。不知道这种情况大家如何处理。
2.如果所用的级联关系都没有设置，全部由业务来决定
a.如果用户在前台在保存User时，设置了User中的UserGroup集合，但是UserGroup集合并没有在库中，那么我们要先保存UserGroup集合到数据库中，同时UserGroup又包含Role的集合，也是先保存到数据库中，因为是EJB项目涉及到远程调用，确保一次调用能做更多的操作。
    这样的话，会发现UserService会有很多代码会和UserGroupService相同，因为保存User的时候涉及到UserGroup保存，可能还会涉及到查找，这样如果不是代码copy，就是UserService依赖UserGroupService显然不合理，当然UserGroup和UserService可以合并成一个Service，但是可能会导致合并后的Service膨胀。可能是Service划分不合理，不知道大家是怎么处理的。
b.鉴于以上原因UserGroupService和UserService仅仅处理简单的插入，处理简单的关系，然后提供一个供远程调用的会话门面，门面中包含UserGroupService和UserService，然后处理关系，可以很好解决a中遇到的情形，但是会发现service中有很多方法只是简单的调用dao中的方法，另外门面中也有很多方法只是简单的调用service中的方法，感觉处理的很别扭。
    各位牛人，大家一起交流一下，不知道大家理解清楚了没有？

    级联关系是必要的，我觉得最好了User级联UserGroup，UserGroup级联Role，不然肯定会产生抛了了异常而不知道是什么异常的情况。

    引用你的话“ 这样的话，会发现UserService会有很多代码会和UserGroupService相同，因为保存User的时候涉及到UserGroup保存，可能还会涉及到查找，这样如果不是代码copy，就是UserService依赖UserGroupService显然不合理”，我觉得在一个模块中这两个service有依赖是很正常的事情；如果你的userGroupService中有对UserGroup进行验证之类的处理，可以用一个UserGroupManager来处理，这样可以复用了。

    再则我认为这里用门面模式来处理是不恰当的，当然有些人可能认为恰当，也是有他个人见解的。门面模式是为了把组件折开，但是又要让他们完成不同功能的组合。你这个除了新建一个用户（同时会新建用户组、角色）时调用保存用户（级联保存其他信息，没有就不保存），还有其他的地方会产生新用户并保存吗？Hibernate的优点就是可方便用户级联保存对象，如果不用的话，不知道后来看你代码的人有何看法。

个人觉得啊，如果说你准备设置多对多关系，最好拆成两个一对多，你可以把原来的关联表简单地做成一个类，再和你的用户，用户组什么的进行关联，这可能会产生一个基本上没什么实际业务意义的domain对象，但我想应该可以简化你的关系的处理，service中，你可以调用多个dao来添加用户，添加用户组，赋权限等，至于是不是用级联，那看你自己的需要了

我与楼上相反，我认为多对对关联映射比两个一对多要好

我也比较喜欢把一个many-to-many的关系分成两个many-to-one的关系。

感觉关系处理还是优点麻烦

个人觉得多对多应该拆成两个一对多去映射

遇到过和LZ差不多的问题。我们是
User与Department多对多
User与Role多对多

我当时做的时候是建立了
Userdept
   --id，userid，deptid
Userrole
   --id，userid，roleid
两个中间表来管理这两个多对多的关系。

个人感觉没必要用级联，直接业务处理就可以了，我们公司就这样做的，挺好的！

挨个回答你的问题哈，个人意见：
1.插入UserGroup的时候，你可以先判断一下腰插入的User是否唯一，当然，这个要在业务逻辑中进行判断。
2>a:如果发现UserService会有很多代码会和UserGroupService相同的话，你也可以将相同的代码提取出来在另外一个Service里面做文章，然后用UserGroupService和UserService继承它。
2>b:这个就是程序的架构和对程序可扩展性的取舍了。如果你觉得这样直接调用dao里面的方法就可以，而且可以保证以后如果需求变更以后，你这个Service不会变，那其实这个service就没有什么意义，去掉也无妨。但是一般不支持这么做，业务的需求变更谁能说的准呢？而且，那样的话，整个程序的层次也就乱了。