what's better for JPA/Hibernate composite primary keys, @IdClass or @EmbeddedId implementations and why?
This is an intentionally naive question. I decided to use @EmbeddedId (for whatever reason) and I feel like I made the wrong choice. Dereferencing the embeddedId that contains the column properties is redundant and quite error-prone when coding.
Are there any more reasons for and/or against the other? Is the a recommendation by the JPA (spec)?
First, if possible, avoid composite ids at all costs. But if you really need, I would recommend @EmbeddedId.
@IdClass is basically a leftover from EJB 2.1 times to make it easier from migrating from BMP. In some other rare corner cases it may be better than @EmbeddedId too. However, generally @EmbeddedId is better and more OO since it encapsulates the concept os the key much better in the object.
You may want to use @AttributeOverride(s) if you need in the key field.
I don't see why do you think that dereferencing the embedded id is redundant and error-prone.
As Pascal wrote here's part of the answer:
Which annotation should I use: @IdClass or @EmbeddedId
In the end, I believe using @IdClass is much easier in practice, because you have to add the embeddedId property name to dereference PK properties, while these aren't written for all non-PK properties.
You always have to remember exactly which properties are part of a PK and those which are not. That complicates writing JPQL queries unneccessarily.
Also, AFAIK the JPA 2.0 spec allows you to put @Id onto @XToX/@JoinColumn/s properties and it introduces the @MapsId annotation, so that mapping identifying relationships (a.k.a. derived identifiers in JPA) are more natural to implement.
I. Remember using idclass to do it. But I'd recommend doing everything you can to avoid multi field keys. They just create extra work.
来源：https://stackoverflow.com/questions/4024800/jpa-hibernate-whats-better-for-composite-primary-keys-idclass-or-embeddedid