重写eq/hc方法有必要区分POJO一对一、一对多和多对多的情况吗?

本文探讨了在ORM框架中实体对象的equals与hashCode方法实现问题,尤其是在一对多或多对多关系中如何避免使用ID作为比对依据,以防在业务关键属性为空时导致错误的判断。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

(起个标题很头疼……表达能力相当差)

[url]http://www.iteye.com/post/47540[/url]
看了上面的那个帖子后,我觉得有必要区分。

分析了一下,帖子里说ID作为主键会出问题主要是在用到Set的情况下(也就是一对多或者多对多),比如说某用户保存了两个新建的email。
[code]
......
User user = session.load(User.class,new Integer(1));
Email e1 = new Email();
Email e2 = new Email();
e1.setAddress("xxx@xx.com");
e2.setAddress("yyy@yy.com");
user.getEmails().add(e1);//这时候id为null,即使equals方法里逻辑是“id为空则返回false”
user.getEmails().add(e2);//hashcode值又该如何计算?所以这时候eq/hc方法要用业务关键属性来写
session.save(user);
.....
[/code]

但业务键值比对的方法有时候好像又不适用
举个例子吧:
一对一的情况。现在有两个表,用户表和用户联系方式表,用户表作为主表,联系方式表的主键作为外键与用户表关联。联系方式表除了主键其余字段都可为空,这时候如果用“值比对”的方式写eq/hc,很有可能逻辑上应该不相等的两个对象equals的结果是true(比如说两个不同对象的所有属性值都为空),得到的hashcode也是一样的。这时候为了避免这个问题,eq/hc方法可以用id来写。因为是一对一的关系,用不到Set,所以也不会产生上面提到的问题。

总结了一下,就是:
1、不改写eq/hc,在跨session操作时会出现问题;
2、一对多或者多对多关系中,pojo的eq/hc不能用id来写,而应该用业务关键属性来写;
3、一对一关系中,pojo的eq/hc可以用id来写,如果用属性值比对反而有可能出问题。


以上只是个人观点,不知道对不对。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值