Hibernate: 1:n Relation

[schalentier]

Hallo,

ich hab eine sticknormale 1:n Beziehung mit Hibernate:

public class Book {
   ...
   @ManyToOne @JoinColumn( name="category_fk" )   
   public Category getCategory() {
      return this.category;
   }
   ...
}

public class Category {
   ...
   @OneToMany( mappedBy="category" )
   public List<Book> getBooks() {
     return this.books;
   }
   ...
}

Nun will ich folgendes:

Book book;
Category cat;

cat = createCategory( ... );
book = createBook( ... );

book.setCategory( cat );
getBookDAO().save( book );

getCategoryDAO().refresh( cat );
assertEquals( "1 book in category", 1, cat.getBooks().size() );

Das funktioniert so, allerdings nur mit diesem refresh. Ist auch logisch, die Book-Liste wird von Hibernate erst mit dem refresh gefuellt. Allerdings gefaellt mir das so nicht (fehleranfaellig, falls ich den refresh mal vergesse und eine sinnlose SQL Abfrage).

Ich koennte die Book.setCategory Methode so schreiben:

public void setCategory( Category category ) {
   this.category = category;
   category.getBooks().add( this );
}

Analog eine Category.addBook Methode:

public void addBook( Book book ) {
   book.setCategory( this );
}

Ist das ein korrektes Vorgehen, oder gibts da irgendein tolles Pattern fuer? Wie geht ihr mit solchen bidirektionalen 1:n-Beziehungen um?

 

[maki]

Bi-Direktionale Assoziationen sind immer etwas komplexer als Unidirektionale.

Es empfiehlt sich doppelte Logik zu vermeiden, daher finde ich deinen Ansatz gut.

 

[Gast]

Hallo,

Wieso benoetigst du eine Wechselseitige Abhaengigkeit ?

Nachteile:

Wie der Name schon sagt ist es eine wechselseitige Abhaengigkeit, d.h. der Wartungsaufwand wird deutlich erhoeht und die Klassenstruktur irgendwann ziemlich unuebersichtlich.

Loesung des Problems:

Navigation entweder in den Kategorien ermoeglichen (1. getBooks():Iterable<Book>) oder in der Book Klasse (2. getCatagory():Catagory).

Bei Lsg 2: Zur Abfrage: Welche Buecher einer Kategorie zugeordnet sind kannst du einfach im DAO eine entsprechende Methode erstellen oder es gibt sicherlich eine Klasse Buchverwaltung in der dann eine Methode (getBooksBy(catagory : Catagory):Iterable<Book>) zu finden ist. Diese iteriert dann die Buecher durch und testet, ob die Kategorie gesetzt ist bzw. hat Zugriff auf den DAO.

Statt Buchverwaltung koennte man das uebrigens auch BookService nennen.

Gruesse

 

[schalentier]

Wieso benoetigst du eine Wechselseitige Abhaengigkeit ?

Wieso nicht? Ich bins von einem anderen Framework (Nicht-Java) so gewohnt. Zudem gehoert das doch eigentlich ("semantisch") in die Datenschicht und nicht in die Serviceschicht, oder?

Wenn ich zu dem Buecherbeispiel ein UML zeichne, hab ich eine Assoziation (1:n) zwischen Category und Book. Und ich will die eben bidirektional.

Sei's drum. Ich habs jetzt wie oben gezeigt geloest, mit der Aenderung, dass ich

category.getBooks().add( this );

in eine (protected) Methode ausgelagert habe (Category.internalAddBook( Book book )). Wahrscheinlich meinst du das mit der zunehmenden Unuebersichtlichkeit.

Komisch finde ich, dass es scheint, als sei ich irgendwie der einzige, der dieses Problem hat. Hab ewig lang gegoogelt und Hibernate-Dokumentation gelesen. In letzterer steht dazu auch nicht mal ein Hinweis, obwohl es ein extra Kapitel ueber bidirektionale Relationen gibt...

 

[byte]

Ich verstehe das Problem nicht so ganz. Du musst die Referenzen halt händisch setzen. Das macht Hibernate nicht von alleine (kann er auch gar nicht).
Ich würde einen oder beide Foreign Keys auf "not null" setzen. Dann bemerkst Du fehlende Referenzierung sofort beim Speichern.

 

[schalentier]

???:L

Ich hab eine 1:n Beziehung, d.h. auch nur einen ForeignKey. Das Referenzenaufloesen macht Hibernate auch, nur eben erst nach dem refresh (und dabei per SQL-Statement). Ich moechte aber auf beide Enden der Assoziation innerhalb der gleichen Transaktion zugreifen. Aber wie gesagt, es klappt ja nun, mit nur wenig mehr Overhead.

 

[byte]

Könnte auch daran liegen, dass Category der Owner der Beziehung ist. Oder an der Bag-Semantik, die ich übrigens tunlichst vermeiden würde. Entweder Du benutzt Set oder List mit @IndexColumn. Bag-Semantik erzeugt teilweise üble SQL-Statements.