DAO, Hibernates

[Guest]

Hallo

folgendes:

Hab eine Klasse User und eine Klasse Role. Hab nun alles schön mit Annotations versehen, und zu Testzwecken createUser, deleteUser usw... geschrieben funktioniert alles super (Hibernates). Nun habe ich folgendes gelesen: Die Hibernate-spezifischen Datenbankzugriffe sollten in eigenen Klassen, sog. Data-Access-Objects - gekapselt werden, damit die Controller unabhängig von Hibernate nur mit DAO-Methoden arbeiten und damit ein möglicher späterer Austausch der Persistenzschicht auf eine andere Technologie erleichtert wird.

frage:

brauch ich nun für jede meiner Klassen eine weiter Klasse UserDAO und RoleDAO oder reciht dort eine zentraleDAO klasse?! hab das irgendwie mit DAO noch nicht so genau verstanden ... ?!

danke im voraus

 

[SnooP]

Das kommt darauf an ... prinzipiell kann es nicht schaden, zu jeder Entität auch ein passendes DAO zu haben... aaaber: Man sollte schon gucken, ob man es überhaupt braucht oder ob für diverse Anwendungsfälle ein generisches DAO reicht. Ich hab z.B. für simple Crud-Operationen eine Klasse DAO, die z.B. Speichern und Löschen von Objekten anbietet.
Beim Holen von Daten ist das manchmal etwas schwieriger - meist will man ja nicht nur einfach über den "PrimaryKey eines Objekts" gehen sondern hat schwierigere Abfragen - in solchen Fällen bietet es sich förmlich an, diese Abfragen in eigenen DAOs auszulagern, die nur für diese Entität gelten.

Manche Ansätze gehen übrigens dann noch weiter und packen die Modellobjekte aus Hibernate noch in Transfer Objects um sie dann an die Presentation-Schicht weiterzuleiten... das halte ich vielfach für übertriebene Vorsicht - zu viel Kapselung und Schichtung kann auch mal ganz schnell zu übertrieben viel Overhead und Stumpfsinnigkeit führen

take care...

 

[byte]

What SnooP said...

Tipps für generische DAOs: http://www.hibernate.org/328.html

 

[ms]

Manche Ansätze gehen übrigens dann noch weiter und packen die Modellobjekte aus Hibernate noch in Transfer Objects um sie dann an die Presentation-Schicht weiterzuleiten... das halte ich vielfach für übertriebene Vorsicht - zu viel Kapselung und Schichtung kann auch mal ganz schnell zu übertrieben viel Overhead und Stumpfsinnigkeit führen

Transfer Objects dienen, wie der Name schon sagt, zum Transferieren. Wenn also die Präsentationsschicht auf einer anderen Maschine läuft bleibt dir gar nichts anderes übrig als die Hibernateobjekte in solche zu wandeln weil es mit ziemlicher Wahrscheinlichkeit keine Hibernatesession auf der anderen Maschine gibt die man fürs lazyloading ev. benötigt.

ms

 

[SnooP]

jaa... wie gesagt - "vielfach" ...

 

[maki]

TOs haben ihre Tücken und machen die Sache oft unnötig kompliziert, davon ist man eher abgekommen, sieht man zB auch an der EJB 3 Spek.

Transfer Objects dienen, wie der Name schon sagt, zum Transferieren. Wenn also die Präsentationsschicht auf einer anderen Maschine läuft bleibt dir gar nichts anderes übrig als die Hibernateobjekte in solche zu wandeln weil es mit ziemlicher Wahrscheinlichkeit keine Hibernatesession auf der anderen Maschine gibt die man fürs lazyloading ev. benötigt.

Eine Alternative wäre ein Domain Model (POJOS) zu verwenden und die Objekte dann als sog. detached objects zu "verschicken", müssen natürlich serialisierbar dafür sein.

Um das problem mit dem Lazyload in den Griff zu bekommen gibnt es mehrere Möglichkeiten, eine der sinnvolleren ist, die use cases genauer auszuarbewiten, so braucht man keine "echten" Objekte zB. für Listen, da reichen oft die Proxies von Hibernate, falls dann ein Datensatz angezeigt/editiert/gelöscht werden soll, wird das echte Objekt geladen.