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

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

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

分析了一下，帖子里说ID作为主键会出问题主要是在用到Set的情况下（也就是一对多或者多对多），比如说某用户保存了两个新建的email。

......
User user = session.load(User.class,new Integer(1));
Email e1 = new Email();
Email e2 = new Email();
e1.setAddress("[e-mail]");
e2.setAddress("[e-mail]");
user.getEmails().add(e1);//这时候id为null，即使equals方法里逻辑是“id为空则返回false”
user.getEmails().add(e2);//hashcode值又该如何计算？所以这时候eq/hc方法要用业务关键属性来写
session.save(user);
.....

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

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


以上只是个人观点，不知道对不对。

评论

4 楼 打倒小日本 2007-11-19  

其实这个问题也就是在"新建"并同时设置"关联"的情况下才会发生
一般只要将这两步分开来做,也就没问题了
副作用是会多一条UPDATE语句
但一般系统的瓶颈都是出现在查询
更新操作还是比较少的

3 楼 qmy 2007-11-16  

我想，如果Hibernate官方的意思是推荐无论什么情况都使用业务关键属性来重写eq/hc，那至少我遇到的那种情况也得有一个解决方案。

或者说……难道我这样建表是不对的？用户表和联系方式不应该分开吗？

2 楼 qmy 2007-11-16  

谢谢“打倒小日本”，这样是解决了问题。不过在多对多关系中，这方法就行不通了吧。

我搞不明白的是：Hibernate官方不推荐用id来重写eq/hc，究竟是因为什么呢？仅仅因为对象在自由状态的时候id为null而不推荐使用来重写吗？

如果是这样的话，那只要在多对多关系中避免使用id重写eq/hc就可以了，是这样吗？

1 楼 打倒小日本 2007-11-16  

一对多 一般都是多方设置一方

Email e1 = new Email();  
Email e2 = new Email();  
e1.setAddress("[e-mail]");  
e2.setAddress("[e-mail]");  
e1.setUser(user);
e2.setUser(user);
session.save(e1); 
session.save(e2); 

这样就不会出现上述问题了