JPA / Hibernate: что лучше для составных первичных ключей, реализаций @IdClass или @EmbeddedId и почему?

Question

что лучше для составных первичных ключей JPA / Hibernate, реализаций @IdClass или @EmbeddedId и почему?

Это намеренно наивный вопрос. Я решил использовать @EmbeddedId (по любой причине), и я чувствую, что сделал неправильный выбор. Разыменование встроенного идентификатора, содержащего свойства столбца, является избыточным и весьма подверженным ошибкам при кодировании.

Есть ли еще причины для и / или против другого? Является ли рекомендация JPA (спецификация)?

Answer 1

Во-первых, если возможно, избегайте составных идентификаторов любой ценой. Но если вам действительно нужно, я бы порекомендовал @EmbeddedId.

@IdClass - это, по сути, остаток от EJB в 2,1 раза, чтобы облегчить переход с BMP. В некоторых других редких случаях это может быть лучше, чем @EmbeddedId. Однако, как правило, @EmbeddedId лучше и лучше ОО, так как он гораздо лучше воплощает концепцию ключа в объекте.

Вы можете использовать @AttributeOverride(s), если вам нужно в поле ключа.

Я не понимаю, почему вы думаете, что разыменование встроенного идентификатора избыточно и подвержено ошибкам.

Answer 2

Как писал Паскаль, вот часть ответа:

Какую аннотацию мне следует использовать: @IdClass или @ EmbeddedId

В конце концов, я считаю, что на практике использовать @IdClass намного проще, потому что вам нужно добавить имя свойства embeddedId для разыменования свойств PK, хотя они не записаны для всех свойств не-PK.

Вы всегда должны точно помнить, какие свойства являются частью ПК, а какие - нет. Это усложняет написание JPQL-запросов без необходимости.

Кроме того, AFAIK спецификация JPA 2.0 позволяет помещать @Id в свойства @XToX / @JoinColumn / s и вводит аннотацию @MapsId, так что сопоставление идентифицирующих связей (или производных идентификаторов в JPA) более естественный для реализации.

Answer 3

I. Не забудьте использовать idclass, чтобы сделать это. Но я бы рекомендовал сделать все возможное, чтобы избежать использования нескольких полей. Они просто создают дополнительную работу.