Какова лучшая практика при реализации equals () для сущностей с сгенерированными идентификаторами

Question

Если у меня есть таблица с колонками A, B, C, D
A: автоматически сгенерированный идентификатор (PK)
B & C: комбинация должна быть уникальной (это столбцы, которые фактически определяют идентичность в деловом смысле)
D: некоторые другие столбцы

Теперь, если я создам бизнес-объекты на основе этой таблицы (например, в Java), какая из них будет лучшей реализацией метода equals ():

1. определить равенство на основе A
2. определить равенство на основе B и C

или, на самом деле не имеет значения, какой из двух я выберу.

Answer 1

Определенно B и C, потому что вы хотите, чтобы контракт equals() был действительным даже до сохранения сущностей.Вы говорите себе:

это столбцы, которые фактически определяют идентичность в деловом смысле

Если это так, то логика equals() должна использоваться,Ключи базы данных относятся к базе данных и не должны затрагивать ваш бизнес-уровень.

И не забывайте использовать те же свойства и в hashcode().

Answer 2

Я тоже согласен с @ S.P.Floyd. Но я хотел добавить что-то еще.

Бывают ситуации, когда у субъекта нет уникальных бизнес-свойств. Например, у объекта могут быть только A (PK) и B (бизнес-свойство), но многие объекты имеют одинаковое значение B.

В этом случае сложно создать equals() и hashcode(). Вы, конечно, не хотите основывать их на A, так как вы не сможете сравнить постоянный объект с тем, который еще не был сохранен. И вы не можете основывать его только на B, потому что тогда многие объекты, которые являются разными уникальными объектами, будут казаться одинаковыми.

Что я делаю в этих ситуациях, так это свойство Date created = new Date();. Когда объект создается, он автоматически получает созданную временную метку. В мои equals() и hashcode() я включаю и B, и created. Это не идеально, так как очень маловероятно, что два объекта могут быть созданы одновременно (особенно в кластерном решении), но это только начало. Если необходимо, добавьте UID или другое сгенерированное бизнес-свойство, которое не является PK базы данных.

Answer 3

Если (B, C) - уникальная пара, дополнительно не требуется автоматически генерируемый идентификатор.Для таблицы A эквивалентно (B, C) (отношение один к одному).

Возможно, вам понадобится или понадобится дополнительный ключ, но я согласен с seanizer, используйте (B, C) дляравно и поскольку A избыточен (и null до сохранения объекта), не используйте его для равенства (и хэш-кода)