Hibernate的关系映射如一对多,为什么要做成双向然后加inverse="true"?
直接做单向不是更简单吗?这样做有什么意义?一楼的答案很明白,但是我的疑问还没解决。换个说法:双向的一方放弃关系的维护和单向意义相同吧,还是这样的双向使用时有单向不具有的优...
直接做单向不是更简单吗?这样做有什么意义?
一楼的答案很明白,但是我的疑问还没解决。
换个说法:双向的一方放弃关系的维护和单向意义相同吧,还是这样的双向使用时有单向不具有的优势。
如果一样,那么inverse="true"不是没有存在的必要吗?
是不是这样:双向的一方放弃关系的维护,但是双向的A到B B到A的联系都好用,只是由单一的A到B维护双向的联系? 展开
一楼的答案很明白,但是我的疑问还没解决。
换个说法:双向的一方放弃关系的维护和单向意义相同吧,还是这样的双向使用时有单向不具有的优势。
如果一样,那么inverse="true"不是没有存在的必要吗?
是不是这样:双向的一方放弃关系的维护,但是双向的A到B B到A的联系都好用,只是由单一的A到B维护双向的联系? 展开
3个回答
推荐于2017-10-04 · 知道合伙人数码行家
关注
展开全部
在Hibernate中,术语inverse是反转的意思,在关联关系中,inverse="false"为主控方,由主控方负责维护对象的关联关系。所以上面的映射文件改动之后,address为主控方,people为被控方,但是测试代码只进行了一个保存操作session.save(people),这是针对people的,因此无法正确级联保存address。而原来的映射文件中(虽然没有明确指明,Hibernate默认inverse="false"),people为主控方,因此保存people时它会保证关联的address的正确保存。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
举个例子,user和account 是一对多关系,
如果你需要通过user找account,也需要通过account找user,这时候才需要做成双向的,双向的效率不高,所以加inverse="true"的一方放弃维护到对方的关系,提高效率。
同样的,如果只需要通过user找account,你可以大胆的设计成user到account的单向一对多关系。一点问题也没有。
根据实际的需要选择单向还是双向。在实际应用中,单向关系是非常多的
如果你需要通过user找account,也需要通过account找user,这时候才需要做成双向的,双向的效率不高,所以加inverse="true"的一方放弃维护到对方的关系,提高效率。
同样的,如果只需要通过user找account,你可以大胆的设计成user到account的单向一对多关系。一点问题也没有。
根据实际的需要选择单向还是双向。在实际应用中,单向关系是非常多的
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询