# Dao



## lernen.2007 (16. Februar 2008)

Hallo Leute,

ich habe in  genug gesucht aber habe immer voll verschiedene Definitionen für DAO gefunden. Was bedeutet eigentlich DAO und wie ist es die Beziehung zu Java?

Gruß
lernen.2007


----------



## Stigma (16. Februar 2008)

Dieser Link ist sehenswert:
http://www.tutego.com/blog/javainsel/2005/12/mit-spring-und-dem-jdbctemplate-auf.html



> Eine DAO Klasse, die Methoden zum Zugriff auf einzelne persistente Entitäten
> erlaubt. Neben den üblichen CRUD-Operationen (Create/Read/Update/Delete)
> kann man zum Beispiel auch die Suche nach einzelnen Attributen durch
> Markierung der betreffenden Attribute im Modell generieren lassen.


----------



## Thomas Darimont (17. Februar 2008)

Hallo,

ein DAO (Data Access Object) oder neuerdings auch Repository genannt ist eine Abstraktion der Persistenzsschicht zur einfachen interaktion mit der Geschäftslogikschicht. Ein DAO kann mehr Funktionalität liefern als nur einfache CRUD (Create Read Update Delete) Operationen. Beispielsweise Daten für einen komplexen Report abrufen etc.
Dabei kann das Repository sowohl auf einem O/RM und sowohl als auch auf plain JDBC basieren.

Gruß Tom


----------



## lernen.2007 (17. Februar 2008)

Hallo,

kann ich mir es denn so vorstellen, daß ich einfach ein Object Referenz speichere um damit nachher damit auch wieder arbeiten kann? Es ist einfach DAO-Pattern, das mit Factory und Strategie Pattern arbeitet. Oder liege ich falsch?

Gruß
lernen.2007


----------



## Oliver Gierke (17. Februar 2008)

Ein DAO Pattern ist ein DAO Pattern. Das Pattern selbst ist sehr klein. Also klein, in dem es eigentlich nur die Vorgabe macht, dass man Datenzugriffslogik für eine Klasse (z.B. User) in ein separates Data Access Object verlegen sollte, z.B. um die Logik in User nicht von der konkreten Persistenzimplementierung abhängig zu machen.

Okay, nun hast du also zwei Objekt um mit einem Benutzer zu arbeiten. Den User selbst und sein DAO. Jetzt stellt sich noch die Frage wie der Code aussieht, der damit arbeiten soll. Und da kommen dann die Themen Factory und Strategy ins Spiel.

Factory braucht man nicht unbedingt, wenn sich der Client die DAO Instanz z.B. per Dependency Injection geben lässt. Ansonsten lässt man sich von der Factory die Instanzen erzeugen.

Um nun Abhängigkeiten zu minimieren und Austauschbarkeit zu gewährleisten, führt man ein Interface für das DAO ein -> Strategy Pattern. Dadurch ist der Client nur noch vom DAO Interface abhängig und kann v.A. leichter getestet werden. Recht theoretischer Vorteil ist auch, dass man eine JDBC DAO Implementierung gegen eine mit Hibernate austauschen könnte oder von MySQL auf Oracle wechselt oder oder oder. Tut niemand, das Austauschen gegen ein Mock zum Testen ist dagegen sehr viel verbreiteter.

Gruß
Ollie


----------



## lernen.2007 (17. Februar 2008)

Endlich mal jemand der die Sache einfach und nicht mit schweren oder unverständlichen Begriffen erklären kann. Danke. Jetzt habe ich es richtig verstanden.

Gruß


----------



## Oliver Gierke (18. Februar 2008)

*gg* naja, mit dem Post hätte ich aber auch problemlos in einem Informatiker Bullshit Bingo gewinnen können . Aber wenns dich voran bringt, umso besser 

REINHAUN!


----------

