Verständnisproblem DAO

[Svenni]

Hallo!
ich beschäftige mich momentan mit Hibernate und wollte zum Üben einfach mal ein kleines Beispielprojekt implementieren. Die Präsentation der Daten erfolgt über JSF. Das ist zunächst kein Problem. Bisher hab ich dann die Zugriffe auf die Datenbank in einer Klasse gekapselt, die dann z.B. Methoden wie getAppointmentById etc. enthält (es ist eine kleine Terminverwaltung). Die ManagedBeans rufen dann diese Methoden auf, da ich den Datenbankzugriffscode nicht in den ManagedBeans drin haben wollte.

Nun habe ich mittlerweile aber schon oft vom DAO-Pattern gelesen. Wenn ich es richtig verstanden habe gehts dabei darum, dass ich zusätzlich zu meiner Entität eine Klasse implementiere, die den Zugriff auf die Entität kapselt. Ich hab dann also nicht mehr nur Appointment sondern auch AppointmentDAO. Die DAO-Klasse enthält dann wohl typischerweise Methoden wie get... delete... update etc. Ist das soweit richtig? Als Vorteil finde ich häufig, dass man sich dadurch nicht von einer Datenbank bzw. Persistenzimplementierung abhängig macht. Es ist demnach leichter später von MySQL auf Oracle zu wechseln oder eben nicht mehr Hibernate zu nutzen, sondern was anderes. Klingt prinzipiell ganz logisch, aber brauch ich das für einfache Anwendungen, bei denen klar ist das sich das nicht ändert wirklich?? Was ich mich gerade beim Schreiben gefragt habe: Wenn ich eine zentrale Zugriffsklasse habe, die den ganzen Zugriffscode für die Datenbank enthält, dann ist diese Klasse eigentlich doch auch eine Art DAO oder?

Dann habe ich auch noch gefunden, dass man zusätzlich zur DAO-Klasse häufig noch ein DAO-interface einführt. Auf diese Weise kann ich dann gegen das Interface implementieren. Zum Zugriff auf eine Instanz einer konkreten DAO-klasse kann man dann eine DAO-Factory einsetzen. Die Situation ist (meiner bisherigen Vorstellung nach) demnach so:

- Entität XYZ
- DAO XYZDAO
- DAO Interface XYZDAOInterface
- DAO Factory XYZDAOFactory

Das ganze "Paket" brauch ich dann für alle Entitäten !? So habe ich es verstanden. Ist das in etwa richtig?

Die Frage ist also, ob ich das DAO Pattern im Groben richtig verstanden habe und noch wichtiger, ob man es wirklich immer braucht oder was sonst für den Einsatz spricht, wenn klar ist das die Persistenzimplementierung und die DB sich nicht ändern.
Über Antworten würde ich mich sehr freuen. Danke.

 

[Gelöschtes Mitglied 5909]

DU hast es richtig verstanden und wenn bei dir klar ist dass du nicht wechseln musst, dann liegt es bei dir ob du es weglässt. In der Regel implementiert man es trotzdem, weil man nie wissen kann. Für ein kleines Heimprojekt würde ich es nicht machen, aber beim schaffen schon

 

[Svenni]

Also ist meine bisherige Zugriffsklasse, die sämtliche Zugriffe auf alle Entitäten kapselt, eigentlich eine Art abgeschwächte Version des DAO-Patterns oder?

Stimmt das mit den benötigten Klassen auch, wie ich es skizziert habe. Also die Entity, ein DAO-Interface, die DAO-Klasse die das DAO-Interface implementiert und eine DAO-Factory, die eine Instanz der DAO-klasse zurückliefert?

Wahrscheinlich kann man das auch etwas "aufweichen", in dem man eine abstrakte Klasse zur Verfügung stellt (anstatt ein DAO-Interface) und diese hat dann direkt eine statische Factory-Methode oder?

Danke.

 

[maki]

Hibernate?
Nach JPA manier oder "den alten Weg"?
Für letzteren Fall gibt es ein generisches Dao auf der Hibernate Webseite, für ersteren nimmt man den EM.

 

[GilbertGrape]

Hm, also ich hab auch nur eine Factory-Klasse für alle DAOs. Allerdings hab ich auch eine abstrakte DAO-Klasse, von der alle meine DAOs abgeleitet sind. Ich glaube, ich hab auch das von der Website als Grundlage genutzt.

 

[Svenni]

Danke für eure Antworten.

Hibernate?
Nach JPA manier oder "den alten Weg"?

Was meinst du mit "alter Weg"? Meinst du damit die XML-Mappingdateien? Ich nutze direkt die Hibernate-Annotationen (da ich auch HQL testweise einsetze).

Ich glaube, ich hab auch das von der Website als Grundlage genutzt.

Ok, dann werde ich mal da nachsehen.