与生成的ID
实现对实体equals()方法时,如果我有一个表列A,B,C,d
一个什么是最好的做法:组合必须是唯一的(这是实际的商业意义定义的身份列)
d:一些列与生成的ID
现在,如果我要在此基础上表中创建的业务对象(如JAVA)哪一个可以更好地实现equals()方法:
- 基于A
- 定义平等基础上B和C
定义平等或者,它不会真的不管我选择哪两个。
肯定是B和C,因为您希望equals()
合同即使在实体持续之前也有效。你说你自己:
这些都是实际 在商业意义
定义的身份。如果是这样的话列,然后就是逻辑equals()
应该使用。数据库密钥是数据库的关注点,应该与业务层无关。
并且不要忘记在hashcode()
中也使用相同的属性。
如果(B,C)是唯一对,则不需要自动生成的ID。对于表格,A相当于(B,C)(一对一关系)。
你可能想要或需要额外的密钥,但我同意seanizer,使用(B,C)的等于和因为A是多余的(并且在对象被持久化之前和null
),不要使用等于和散列码)
我同意@SPFloyd。但我想添加更多。
有些情况下,实体没有独特的业务属性。例如,一个实体可能只有A
(PK)和B
(商业物业),但许多实体具有相同的B
值。
在这种情况下,很难创建equals()
和hashcode()
。您当然不希望将它们基于A
,因为您将无法将持久对象与尚未持久保存的对象进行比较。而且你不能仅仅依靠B
,因为那么许多不同唯一实体的对象看起来是相同的。
我在这些情况下做的是有Date created = new Date();
属性。创建实体时,会自动获取创建的时间戳。在我的equals()
和hashcode()
中,我包括B
和created
。这并不完美,因为两个对象可能同时创建的机会很小(特别是在集群解决方案中),但这是一个开始。如果必须,请添加不是数据库PK的UID或其他生成的业务属性。
为什么在`equals()`方法中排除`A`? – 2010-12-01 10:22:57
因为从业务角度来看,具有相同属性B和C的持久实体和非持久实体是相等的。业务角度不应该关注像DB ID这样的实现细节,这只与模型相关。 – 2010-12-01 10:25:13
谢谢。我认为我在倒退(首先实施,第二个业务意识)。你的回答让我意识到这一点。谢谢。 – 2010-12-01 10:38:52