# DAO, Repository oder was sonst?



## temi (10. Jun 2018)

Ich lese gerade in einem Buch von Michael Inden, der ein DAO ungefähr so definiert (etwas vereinfacht):

```
public class DAO {
    void insert();
    void update();
    void delete();
    List<> queryAll();
    List<> queryForSomethingSpecial();
    // weitere Queries, wenn erforderlich
}
```

Genau dieselbe Definition habe ich auch im web gefunden, da allerdings für ein Repository.

Außerdem noch den folgenden Beitrag https://medium.com/@krzychukosobudzki/repository-design-pattern-bc490b256006, der ein Repository ungefähr folgendermaßen umsetzt:

```
public class Repository {
    void insert();
    void update();
    void delete();
    List<> query(Specification specification);
}
```

Letzteres gefällt mir persönlich am besten, bzw. erscheint mir am flexibelsten, aber was ist denn nun die Wahrheit, bzw. gibt es eine Wahrheit?


----------



## httpdigest (10. Jun 2018)

Ein Repository ist näher am Domainmodell der Anwendung. Ein DAO hingegen näher am Persistenzmodell.
Das heißt, die Schnittstelle eines DAOs bietet Methoden, um konkrete Datenbanktabellen abzufragen und Einträge anzulegen/zu löschen. In den meisten Fällen würde man hier wohl auf ein O/R Mapper wie Hibernate oder EclipseLink zurückgreifen. Damit hättest du dann ein Persistenzmodell, welches deinen Hibernate-gemappten Klassen entspricht.
Wie dein Persistenzmodell nun aber genau aussieht, ist irrelevant. Wenn du keinen O/R Mapper nimmst, könntest du natürlich trotzdem Klassen nehmen.

Auf der anderen Seite steht dein Domainmodell, mit welchem deine Anwendung in der Geschäftslogikebene arbeitet. Das Repository bietet dann eine Schnittstelle, um Persistenzoperationen auf Basis von Objekten des Domainmodells zu bewerkstelligen. Ein Repository kann sich für die Realisierung der Operationen einzelner DAOs bedienen.

Der Unterschied zwischen Domainmodell und Persistenzmodell ist also Separation of Concern. Der Concern des Domainmodells ist es, dass die Geschäftslogikebene damit arbeiten kann. Der Concern des Persistenzmodells ist es, das Modell möglichst so zu reflektieren, wie es in der darunterliegenden Persistenzimplementierung (z.B. relationale Datenbank mit oder ohne O/R Mapper) abgebildet ist.

In vielen Fällen wird bei Anwendungen Domainmodell = Persistenzmodell sein. Das heißt, die Geschäftslogikebene arbeitet direkt auf denselben Klassen wie die Persistenzschicht, die per O/R Mapper realisiert sein kann.

Wenn wir also einfach Domainmodell und Persistenzmodell als gegensätzliche Pole aufzeichnen und Repository und DAO gemäß ihrer Nähe zu diesen Polen darstellen wollen, würde es wohl so aussehen:

Domainmodell <-----Repository-------------DAO-----> Persistenzmodell

Weitere Quellen:
- https://stackoverflow.com/questions...en-dao-and-repository-patterns#answer-8550228
- http://blog.sapiensworks.com/post/2012/11/01/Repository-vs-DAO.aspx


----------



## temi (10. Jun 2018)

Ja, das leuchtet ein.

Danke!


----------

