Repository и DAO: отличия, преимущества, недостатки

3

Давайте соберем и систематизируем информацию об этих подходах к организации доступа к данным. А именно, какая между ними разница, какие преимущества и недостатки у этих паттернов и в каких случаях их применять.

Progg it

Лучший ответ:

3

Прежде чем ответить на все вопросы, предлагаю выяснить назначение и принципы действия каждого из паттернов.

DAO

Итак, паттерн DAO (Data Access Object) получил особо широкое распространение и применение в мире J2EE. Его прямое предназначение — абстрагировать и инкапсулировать доступ к источнику данных. DAO управляет соединением с источником данных для получения и записи данных.

В классическом варианте DAO содержит только стандартные CRUD-методы. Клиент вызывает эти методы получая или передавая в качестве аргумента так называемый DTO (Data Transfer Object).

По сути, DAO является реализацией слоя отображения реляционных данных в объекты и наоборот. Именно здесь сосредотачивается решение проблемы, известной как "Object-relational impedance mismatch".

Repository

Рассмотрим теперь паттерн Repository. Repository выступает в роли посредника между слоем домена и слоем отображения реляционных данных. Он выполняет роль коллекции объектов домена в оперативной памяти. Таким образом, репозиторий представляет собой более высокий уровень абстракции над слоем отображения данных.

Repository является ориентрованным на модель предметной области, в то время как DAO больше ориентирован на источник данных. Это означает, что Repository может содержать методы, возвращающие объекты предметной области, удовлетворящие какому-либо заданному критерию, а также содержать логику конструирования запросов к нижележащему слою (собственно DAO).

Объекты, запрашиваемые у репозитория, могут иметь довольно сложную структуру. Например, объект Employee может содержать ссылку на объект Organization. Для того, чтобы обеспечить корректную работу по сохранению и загрузке подобных объектов репозиторию может понадобиться один или несколько DAO.

Выводы

Что же мы имеем в итоге? Выходит, что вопрос о взаимоисключающем использовании паттернов Repository и DAO несколько некорректен. Эти решения можно задействовать в связке. Применяя Repository как коллекцию объектов в памяти, мы можем поместить DAO на более низкий уровень и инкапсулировать в нем логику обращения к источнику данных. Важно помнить об обязанностях каждого из решений.

Ниже приведу краткий список тезисов, характеризующих различия между Repository и DAO:

  • DAO инкапсулирует доступ к источнику данных
  • DAO является реализацией слоя объектно-реляционного отображения
  • DAO более ориентирован на источник данных
  • Repository представляет более высокий уровень абстракции
  • Repository выполняет роль коллекции объектов домена в памяти
  • Repository ориентирован на модель предметной области
admax

Правильно я понимаю, что если доступ к данным реализуется через ORM-библиотеку, то слой DAO отсутствует и создается только слой репозиториев, которые используют API ORM для получения/сохранения данных?

safonovea

Тоже думал над этим вопросом. Да, наверное, так и есть. Только при использовании репозитория часто забывается про коллекцию уже загруженных объектов, а между тем, на мой взгляд это довольно важный аспект, напрямую влияющий на производительность взаимодействия приложения и БД.

admax

Ну если используется зрелое ORM решение, типа (N)Hibernate, то о кешировании можно особенно не беспокоиться (во всяком случае на уровне репозитория).

v1.7.123.556
© 2009—2010 CodeHelper FAQ | О сайте | Обратная связь | История изменений | Статьи
Тут. Creative Commons LicenseМатериалы сайта распространяются под лицензией Creative Commons Attribution-Share Alike 3.0 Unported.