JPA/Hibernate: Was ist besser für zusammengesetzte Primärschlüssel, @ IdClass oder @ EmbededId Implementierungen und warum?

Was ist besser für JPA/Hibernate Composite Primärschlüssel, @IdClass oder @EmbeddedId Implementierungen und warum?JPA/Hibernate: Was ist besser für zusammengesetzte Primärschlüssel, @ IdClass oder @ EmbededId Implementierungen und warum?

Dies ist eine absichtlich naive Frage. Ich entschied mich für @EmbeddedId (aus welchem Grund auch immer) und ich habe das Gefühl, dass ich die falsche Entscheidung getroffen habe. Die Dereferenzierung der eingebetteten ID, die die Spalteneigenschaften enthält, ist redundant und bei der Codierung ziemlich fehleranfällig.

Gibt es weitere Gründe für und/oder gegen den anderen? Ist das eine Empfehlung der JPA (spec)?

Quelle

2010-10-26 Kawu

mögliches Duplikat von [Welche Anotot sollte ich verwenden: @IdClass oder @EmbeddedId] (http://stackoverflow.com/questions/212350/which-anotation-should-i-use-idclass-or- embeddedid) –

It scheint zu sein. Aber es nennt keine weiteren Gründe. – Kawu

Das Hibernate-Handbuch rät aus unbekannten Gründen gegen @IdClass ab: http://docs.jboss.org/hibernate/annotations/3.5/reference/en/html/entity.html#d0e1112 Vielleicht kann jemand das aufklären? – Kawu

Wie Pascal schrieb einen Teil der Antwort ist hier:

Which annotation should I use: @IdClass or @EmbeddedId

Am Ende ich @IdClass glaube verwenden ist viel einfacher, in der Praxis, weil Sie die embeddedId Eigenschaftsnamen zu dereferenzieren PK Eigenschaften hinzufügen müssen, während diese nicht für alle Nicht-PK-Eigenschaften geschrieben werden.

Sie müssen sich immer genau merken, welche Eigenschaften Teil einer PK sind und welche nicht. Das erschwert das unnötige Schreiben von JPQL-Abfragen.

Auch AFAIK die JPA 2.0-Spezifikation ermöglicht es Ihnen, @Id auf @XToX/@JoinColumn/s Eigenschaften zu setzen und es stellt die @MapsId Annotation, so dass die Zuordnung zu identifizieren Beziehungen (auch bekannt als abgeleitete Identifikatoren in JPA) natürlicher zu implementieren ist.

Quelle

2010-10-27 13:47:39 Kawu

I. Denken Sie daran, IDClass zu verwenden. Aber ich würde empfehlen, alles zu tun, um Multi-Feld-Schlüssel zu vermeiden. Sie schaffen nur zusätzliche Arbeit.

Quelle

2010-12-10 00:36:10 drekka

Gab +1, weil es uns dazu brachte, uns mit Composite PK neu zu bewerten und zu dem Schluss gekommen sind, dass wir viel besser ohne sie wären. – Erikson

Manchmal - insbesondere bei der Arbeit mit einem Legacy-Schema - besteht die einzige Möglichkeit, eine Entität korrekt zuzuordnen, in der Verwendung von zusammengesetzten PKs. Natürlich ist es beim Entwerfen eines neuen Schemas besser, sie (wenn möglich) zu vermeiden. – snorbi

Zuerst, wenn möglich, Composite-IDs um jeden Preis vermeiden. Aber wenn Sie wirklich brauchen, würde ich @EmbeddedId empfehlen.

@IdClass ist im Grunde ein Rest von EJB 2,1 mal, um die Migration von BMP zu erleichtern. In einigen anderen seltenen Fällen kann es auch besser als @EmbeddedId sein. Im Allgemeinen ist @EmbeddedId jedoch besser und mehr OO, da es das Konzept des Schlüssels viel besser in das Objekt einkapselt.

Sie können @AttributeOverride(s) verwenden, wenn Sie im Schlüsselfeld benötigen.

Ich sehe nicht, warum glauben Sie, dass Dereferenzierung der eingebetteten ID redundant und fehleranfällig ist.

Quelle

2010-12-27 19:27:05

Ja, du hast Recht mit deinem letzten Satz. Wenn man die JPA 2.0-Syntax verwenden würde, gäbe es keine redundanten Felder in der Entity-Klasse, so dass Sie die Join-Spalten immer dereferenzieren müssten, was für alle vier zusammengesetzten Key-Vatiants JPA 1.0 @IdClass vorzuziehen scheint. JPA 1.0 @EmbeddedId, JPA 2.0 @IdClass und JPA 2.0 @EmbeddedId. – Kawu

Können Sie erklären, warum zusammengesetzte IDs schlecht sind? – displayname

JPA/Hibernate: Was ist besser für zusammengesetzte Primärschlüssel, @ IdClass oder @ EmbededId Implementierungen und warum?

Antwort

Verwandte Themen