Hibernate Struktur

[Guest]

Guten Morgen,

ich würde gern anfangen mich mit Hibernate zu beschäftigen. Erses lesen und speichern von Daten in der Datenbank klappt soweit auch einwandfrei und somit würd ich gern ein paar Schritte weiter gehen und eine kleine Anwendung schreiben.

Problem:
Ich tu mich ein wenig schwer was die Struktur des ganzen angeht und konnte auch leider keine kleine Beispielapplikation fionden wo man sich das ganze einmal genauer anschauen könnte.

Wie strukturiert man denn nun "am besten" sein Hibernate Projekt?
Was ich bisher gesehen habe war, das ich für jede Tabelle eine Klasse habe die diese Tabelle abbildet, die POJO Klasse wenn ich nicht irre.

Da diese POJOS nur get und set Methoden aufweisen, gibt es für jedes POJO noch eine weitere Klasse die das speichern, updaten, lesen und löschen anhand der POJOS übernimmt und auch sonstige Anwendunslogik enthalten kann?

Wie strukturiert Ihr denn eure Anwendungen mit Hibernate? Hab ich einen groben Fehler in meiner Überlegung? Hilfe

 

[SnooP]

Schau dir am besten mal das DAO Pattern an... ich habe z.B. ein generisches DAO für das Speichern/Erstellen/Löschen der Objekte (Pojos) während für diverse Abfragen zum Holen der Objekte spezielle DAOs verwendet werden.
Sprich Pojo Auto --> AutoDAO mit Methoden für spezielle Abfragen zum Holen von Autos. z.B. gib mir alle Autos mit Farbe 'gelb'.

Ebenfalls richtig erkannt - du brauchst für alle darzustellenden Tabellen eine entsprechende Mapping-Klasse und je nachdem ob du die xml oder JPA Variante verwendest, brauchst du dann noch die hbm.xml Dateien für das Mapping (pro Klasse eine) oder du löst das eleganter via Annotations (JPA-Ansatz).

 

[byte]

Prinzipiell gibts da nicht großartig Unterschiede. POJOs sind ja nichts Hibernate-spezifisches, sondern Teil eines jeden Datenmodells in Java. Vorgehensweise ist also, dass Du die POJOs schreibst. Diese mapst Du dann (per XML oder Annotations) auf die Daten in der DB. Dabei ist zu unterscheiden, ob Du schon bestehende DB-Tabellen mapst oder die Tabellen noch nicht existieren. Zweiterer Fall ist insofern sehr schön, weil dann Hibernate das DB-Schema aus den POJOs generieren kann. Zuletzt schreibst Du Dir die so genannten DAOs, für gewöhnlich für jedes POJO also eine DAO-Klasse mit den Methoden zum Laden, Speichern usw. aus der DB.

 

[SlaterB]

falls du ein großes Beispiel haben willst:
http://www.hibernate.org/400.html

---------

eine weitere Klasse pro POJO ist gar nicht verkehrt, eine DAO-Klasse (DataAccessObject),

muss aber auch nicht unbedingt sein,
wenn du viele einzelne POJOs in unterschiedlichen Gruppen hast,
dann reicht vielleicht eine DB-Klasse pro Gruppe,

und ein großer Vorteil von Hibernate ist ja, dass die Objekte automatisch untereinander vernetzt werden,
du lädst das POJO Schulklasse sk mit Hilfe des SchulklasseDAOs und bekommst die Liste der Schüler einfach mit
sk.getSchueler()
statt umständlich ein anderes DAO zu einer neuen DB-Ladeoperation zu bewegen,

dafür muss natürlich irgendwo konfiguriert sein, dass jedem Schulklasse-Objekt die Schüler zugeordnet und intern geladen werden,
nicht ganz einfach am Anfang (Frendschlüssel in DB, 1 zu n Beziehung usw)
das nur als Ausblick auf die Möglichkeiten,

einfach ein Lehrbuch/ Tutorial entlang für die ersten Schritte

 

[Gast]

das mit den miteinander verbundenen objekten etc. pp. hatte ich schon verstanden und funktioniert soweit auch.

das mit den pojo klassen ist also richtig, dienen denn die entsprechenden dao klassen dann ausschliesslich dazu die pojos mit der datenbank in verbindung zu bringen?

 

[SlaterB]

wie du es selber gesagt hast: speichern, updaten, lesen und löschen

 

[Guest]

ok, bis zum ersten update dachte ich alles wäre klar , aber dem ist ganz und gar nicht so :lol:

habe gerdae eben das erste mal den fall gehabt das ich einen datensatz updaten musste und dachte mir:
alles klar, über die setter die werte setzen und dann ganz geschmeidig das POJO ans DAO gegeben und save() aufgerufen, aber pustekuchen!

habe dann in meinem hibernate buch gewühlt und gelesen, das das ändern von objekten mehr oder minder automatisch erfolgt wenn ich eine der setter methoden aufrufe - und das so lange wie die objekte mit der session verbinden sind.

Daraus resultiert bei mir wieder eine Struktur Frage:
Wie hand habt man das mit der Session?

Im Moment habe ich eine zentral erreichbare SessionFactory in meinem System. Von dieser lassen sich die verschiedenen DAOs eine Session überopenSession geben wenn ich z.B. eben etwas aus der DB lesen will. Allerdings schliesse ich meine Session nach dem auslesen immer sofort, ad ich das bisher mit der Arbeit von JDBC so gewohnt war/bin.

Muss ich die Session am POJO halten? Wieviele Session können einfach so offen sein ohne das es kritisch mit der Performance wird? Ist etwas grundsätzlich verkehrt daran die Methoden in de n DAOs alle static zu haben?! Hilfe

 

[byte]

saveOrUpdate() statt save() benutzen.

 

[maki]

http://www.hibernate.org/43.html