JPA - wann Beziehungen zu verwenden?

Question

Ich bin immer noch nicht eine Bühne, wo ich mich mit JPA völlig wohl fühle.

Im Moment bin ich hin und her gerissen zwischen Beziehungsanmerkungen oder einfach die verwandten Objekte abrufen, wenn ich sie mit Abfragen brauche.

Zum Beispiel habe ich einen Benutzer, der Projekte besitzt. Ich kann eine onetomany Beziehung benutzen und die Projekte auf eine objektartige Weise zurückholen ODER ich kann die Projekte des Benutzers einfach abfragen, wenn ich sie benötige.

Die letztere Lösung beinhaltet mehr Code, aber irgendwie habe ich mehr Freiheit und Kontrolle über das, was ich tun möchte, oder zumindest ist es mein Eindruck. Die erstere wird offensichtlich eine ziemlich große Menge an Kesselblech-Code wie das Erstellen/Löschen/Aktualisieren von Objekten erledigen, aber es gibt einige Tricks, die man auf dem Weg lernen kann.

Ich würde mich sehr freuen, wenn jemand eine einfache Faustregel über die Verwendung von Beziehungsanmerkungen in JPA, vorzugsweise basierend auf seiner/ihrer Erfahrung, hätte.

Danke,

Thomas

Answer 1

Die Grundregel ist, dass Sie eine Beziehung erstellen sollten, wenn Sie sie benötigen.

Für One-to-One- und Many-to-One-Beziehungen ist es ziemlich einfach: Sie brauchen sie fast immer. Wenn Sie z. B. Project Informationen anzeigen, müssen Sie fast immer auch dessen Besitzerinformationen anzeigen. Daher ist die Erstellung einer Beziehung hier eine gute Wahl.

Eins-zu-viele- und Viele-zu-viele-Beziehungen erfordern mehr Sorgfalt, da eine zu häufige Verwendung zu Leistungsproblemen führen kann.

Meine persönliche Faustregel lautet wie folgt: Wenn Sie nicht alle Project s von User auf einmal ohne Paginierung oder Filterung anzeigen müssen (oder es zumindest nicht oft tun müssen), erstellen Sie nicht ein Verhältnis. Andernfalls können Sie es erstellen (zum Beispiel benötigen Sie normalerweise alle OrderLine s von Order gleichzeitig, daher benötigen Sie in diesem Fall eine Eins-zu-viele-Beziehung).

Answer 2

, wenn es eine Beziehung zwischen zwei Entitäten ist und Sie erwarten, es zu benutzen, JPA Beziehung Anmerkungen zu verwenden. Einer der Hauptvorteile besteht darin, dass keine zusätzlichen Abfragen manuell erstellt werden müssen, wenn eine Beziehung zwischen Entitäten besteht.

Answer 3

Ich würde für die Anmerkung gehen. Es ist einfacher und produziert weniger Code und es ist irgendwie der ganze Sinn von JPA. Und auch die Eins-zu-Viele-Sätze werden standardmäßig faul abgerufen, sodass Sie nicht riskieren, Daten aus der Datenbank zu holen, die Sie nicht benötigen.

Aber ich empfehle Lesen auf faul/eifrig holen und lernen, wie das funktioniert.

Answer 4

Ihre Probleme sind gültig, Beziehungen sind in JPA-konformen ORMs schwierig. Der Vorteil von Beziehungen besteht jedoch darin, dass sie in JPA-QL-Abfragen verwendet werden können. Z.B. wenn Sie alle Projekte, die von Benutzer mit einem bestimmten Namen erstellt holen möchten, können Sie schreiben:

SELECT p 
FROM Project p 
WHERE p.user.name = 'Smith' 

Sie können dies nicht tun, wenn statt:

@ManyToOne 
private User user 

in der Project Beziehung Sie ein einfaches haben:

Untersuchen Sie auch verschiedene Abrufstrategien, um sich mit Beziehungen wohler zu fühlen.

Answer 5

Es hängt alles davon ab, wie Ihre Anwendung in Bezug auf das Abrufen von Daten und den Instanzen, die sie benötigt, funktioniert. Obwohl JPA überall verwendet werden kann, auch außerhalb eines Java-EE-Containers (was ein großer Vorteil in einer Standard-Java-SE-App oder mit Spring usw. ist), finde ich, dass sich seine Denkweise sehr stark an Request orientiert - Interaktionen im Antwortstil, Zuordnung zu Webanwendungen und Ähnlichem (was fair ist, ist heutzutage die am häufigsten verwendete Art von serverseitiger Unternehmensanwendung). Wenn Sie jedoch keine sehr spezifischen Bedürfnisse haben, würde ich definitiv in das Erlernen der JPA-Beziehungsanmerkungen investieren.

In JPA geht alles um die EntityManager-Sitzung. Wenn Sie eine EntityManager-Instanz haben, die Ihre Entitäten im gesamten Workflow verwaltet, erwähnen Sie, wo Sie Benutzer, Projekte usw. benötigen., alle innerhalb einer Anfrage-Antwort dann definitiv für die Verwendung von @ OneToMany usw., weil es kümmert sich um die Kind-Entitäten zu bekommen, wann immer Sie sie benötigen, ohne sich darum kümmern, wie fremde Schlüssel beizutreten und trägt auch mit Optimierungen auf, wann was abrufen. Selbst wenn Sie die gleiche Entity über Anfragen übertragen müssen, ist es ziemlich einfach mit refresh() und merge().

Ich stimme Ihnen zu, dass die Annotationen mit FetchType, CascadeType etc. etwas haarig werden und Sie könnten auch die gelegentliche berüchtigte cannot simultaneously fetch multiple bags PersistenceException bekommen, also ist es eine holprige Fahrt, aber sobald Sie den Dreh raus, denke ich es ist die Investition wert.