Что такое/чем отличаются Repository и Dao интерфейсы?

Question

[Андрей]

Доброго времени суток.

Просматривал различные репозитории на github, и нашел несколько проектов, где были созданы и DAO интерфейсы для сущностей, и Репозитории для них же, при чем, в большинстве случаев они содержали одни и те же методы (это о интерфейсах). В реализациях было манипулирование dao реализациями, и наложены транзакции.

Собственно, почему нельзя транзакции сделать в dao объектах?
И когда, что и зачем нужно использовать?

Ссылки на репозитории приветствуются,
Также можете порекомендовать пару книг :)

Answer 1

[bromzh]

Вот тутор от оракла, там всё поясняют. И ещё вот, например.
А вообще, с названиями классов в яве всегда были разногласия и путаницы. И часто DAO называют то, что им не должно являться.

По смыслу, DAO - довольно низкоуровневая штука, работает напрямую с хранилищем. Для каждого Transfer Object'а (сущности) должна быть реализация DAO для конкретного хранилища.
Например, есть 2 сущности: User и Post. Есть разные хранилища: 2 SQL базы данных (MySql и Postgres), файловая система, хранилище на основе xml-файлов.
Для объекта User есть интерфейс UserDao с методами CRUD. И должны быть 4 реализации этого метода: MySqlUserDao, PostgresUserDao, FileSystemStorageUserDao, XmlFileStorageUserDao. Аналогично для второй сущности. И обычно создаётся фабрика DAO, которая будет выдавать нужную реализацию (по первой ссылке есть схемы). Ну и в силу похожести реализаций, DAO обычно делают абстрактным и типизированным.
Таким образом, получается унифицированный интерфейс для манипуляции данными. Можно прозрачно сменить хранилище просто выбрав другую реализацию DAO (например, через внедрение зависимостей или конфигов), не меняя бизнес-логику.

Так что обычно DAO создают там, где нет готовой реализации связи с каким-нибудь хранилищем (или эта реализация не устраивает). А те же транкзакции - это более высокий уровень, в DAO их можно не включать, чтобы не усложнять архитектуру и монолитность.

Репозиторий же - это более общая и абстрактная штука.
Вообще, название "репозиторий" обычно встречается в мире спринга, в JavaEE другие термины. Да и суффикс DAO в спринге используется чаще, хотя по смыслу, это не всегда то самое DAO, в толковании Sun/Oracle.

Comments

[Андрей]

" А те же транкзакции - это более высокий уровень, в DAO их можно не включать" их тогда хранить стоит в репозиториях?

"Вообще, название "репозиторий" обычно встречается в мире спринга, в JavaEE другие термины." а какие там термины, например?

И ещё такой вопрос: можно ли унаследовать DAO интерфейс от "репозитрия"(или наоборот), для избежания дублирования кода? Или можно определить какой-то общий интерфейс для обоих (для более понятной иерархии)?

[bromzh]

Андрей: Транкзакции - довольно сложная вещь. На серверах приложений ими могут управлять эти самые сервера. Например, все действия, происходящие в компоненте внедрённым через EJB автоматически будут использовать транзакции.
Сервера следят за контекстом и жизненным циклом приложения и отдельных бинов. Бины, например, бывают stateless и stateful. Первые должны либо подтверждать либо откатывать транкзакцию при выполнении методов, а вот вторые могут быть связаны с транзакцией даже если соединение с БД отключилось.
Если делать вручную, то стартовать и подтверждать (либо откатывать) транзакции нужно в классах с бизнес-логикой, где будет использоваться код. Часто используемый код можно выделить в отдельный класс.

какие там термины, например
В нетбинсе это именуется фасадом (UserFacade). В других источниках их называют сервисами (UserService). В третьих - просто бинами (UserBean). Суть в том, что вся бизнес-логика, относящаяся к сущности User идёт через них.

можно ли унаследовать
Да, по второй ссылке, что я приводил есть пример реализации DAO.
Обычно создаётся абстрактный класс, параметризуемый типом сущностей. В нём содержится большая часть кода. Пример иерархии описан, например, тут ru.stackoverflow.com/questions/299530/%D0%9A%D0%B0...