что лучше для составных первичных ключей JPA/Hibernate, реализации @IdClass или @EmbeddedId и почему?
Это намеренно наивный вопрос. Я решил использовать @EmbeddedId (по какой-то причине) и чувствую, что сделал неправильный выбор. Разыменование встроенного идентификатора, содержащего свойства столбца, является избыточным и довольно подверженным ошибкам при кодировании.
Есть ли еще причины за и/или против другого? Является ли это рекомендацией JPA (спецификация)?
Во-первых, по возможности избегайте составных идентификаторов любой ценой. Но если очень нужно, то я бы порекомендовал @EmbeddedId.
@IdClass в основном является остатком от EJB 2.1 раз, чтобы упростить миграцию с BMP. В некоторых других редких угловых случаях это может быть лучше, чем @EmbeddedId. Однако, как правило, @EmbeddedId лучше и более объектно-ориентированный, поскольку он намного лучше инкапсулирует концепцию ключа в объекте.
Вы можете использовать @AttributeOverride(s), если вам нужно в ключевом поле.
Я не понимаю, почему вы думаете, что разыменование встроенного идентификатора избыточно и подвержено ошибкам.
Как писал Паскаль, вот часть ответа:
Какую аннотацию следует использовать: @IdClass или @EmbeddedId
В конце концов, я считаю, что использование @IdClass на практике намного проще, потому что вам нужно добавить имя свойства embeddedId для разыменования свойств PK, хотя они не написаны для всех свойств, не относящихся к PK.
Вы всегда должны точно помнить, какие свойства являются частью ПК, а какие нет. Это излишне усложняет написание запросов JPQL.
Кроме того, насколько я знаю, спецификация JPA 2.0 позволяет вам помещать @Id в свойства @XToX/@JoinColumn/s и вводит аннотацию @MapsId, так что отображение идентифицирующих отношений (также известных как производные идентификаторы в JPA) более естественно для реализации.
I. Не забудьте использовать для этого idclass. Но я бы порекомендовал сделать все возможное, чтобы избежать ключей с несколькими полями. Они просто создают дополнительную работу.
