В чем разница между объектами доступа к данным (DAO) и шаблонами репозитория? Я занимаюсь разработкой приложения с использованием Enterprise Java Beans (EJB3), Hibernate ORM в качестве инфраструктуры и доменно-управляемого проектирования (DDD) и тест-ориентированной разработки (TDD) в качестве методов проектирования.
Ответы:
DAOэто абстракция постоянства данных .
Repositoryэто абстракция коллекции объектов .
DAOбудет рассматриваться ближе к базе данных, часто на основе таблицы.
Repositoryбудет рассматриваться ближе к домену, имея дело только с совокупными корнями.
Repositoryможет быть реализовано с помощью DAOs, но вы бы не сделали обратное.
Кроме того, как Repositoryправило, более узкий интерфейс. Это должно быть просто набор объектов, с Get(id), Find(ISpecification), Add(Entity).
Подобный метод Updateподходит для a DAO, но не для a Repository- при использовании a Repositoryизменения сущностей обычно отслеживаются отдельным UnitOfWork.
Кажется распространенным видеть реализации, называемые a, Repositoryкоторые на самом деле более a DAO, и, следовательно, я думаю, что существует некоторая путаница в разнице между ними.
Хорошо, думаю, я могу лучше объяснить, что я положил в комментариях :). Таким образом, в принципе, вы можете видеть оба этих варианта одинаково, хотя DAO - более гибкий шаблон, чем Repository. Если вы хотите использовать оба, вы должны использовать репозиторий в ваших DAO. Я объясню каждый из них ниже:
Это хранилище объектов определенного типа - оно позволяет вам искать объекты определенного типа, а также сохранять их. Обычно он будет обрабатывать только один тип объектов. Например AppleRepository, позволит вам сделать AppleRepository.findAll(criteria)или AppleRepository.save(juicyApple). Обратите внимание, что в репозитории используются термины модели предметной области (а не термины базы данных - ничего не связано с тем, как данные хранятся где-либо).
Хранилище, скорее всего, будет хранить все данные в одной таблице, тогда как шаблон не требует этого. Тот факт, что он обрабатывает только один тип данных, делает его логически связанным с одной главной таблицей (если используется для сохранения БД).
DAO - это класс, который определяет местонахождение данных для вас (в основном это средство поиска, но обычно оно также используется для хранения данных). Шаблон не ограничивает вас для хранения данных того же типа, поэтому вы можете легко иметь DAO, который находит / хранит связанные объекты.
Например, вы можете легко получить UserDao, который предоставляет такие методы, как
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
Все они связаны с пользователем (и безопасностью) и могут быть определены в соответствии с тем же DAO. Это не относится к хранилищу.
Обратите внимание, что оба шаблона действительно означают одно и то же (они хранят данные и абстрагируют доступ к ним, и они оба выражены ближе к модели предметной области и почти не содержат ссылок на БД), но способ их использования может немного отличаться, поскольку DAO немного более гибкий / универсальный, в то время как репозиторий немного более конкретен и ограничивает только тип.
CarDescription, например, в language_idкачестве внешнего ключа, - тогда, чтобы узнать, что я должен сделать что-то вроде этого: CarRepository.getAll(new Criteria(carOwner.id, language.id));что даст мне все машины языка на определенном языке - это правильный способ сделать это ?
CarRepository.findByLanguageId(language.id)и вам даже не нужно будет писать код, вы просто определяете интерфейс с помощью метода с таким именем, а Spring Data позаботится о создании для вас реализации класса по умолчанию. Довольно аккуратные вещи;)
findById). И вы практически сделали. Затем Spring Data находит все созданные вами интерфейсы, расширяющие интерфейс Repository, и создает для вас классы. Вы никогда не увидите эти классы и не сможете создавать новые экземпляры, но вам это не нужно, поскольку вы можете просто подключить интерфейс автоматически и позволить Spring найти этот объект репозитория.
Шаблоны DAO и Repository представляют собой способы реализации уровня доступа к данным (DAL). Итак, сначала начнем с DAL.
Объектно-ориентированные приложения, которые обращаются к базе данных, должны иметь некоторую логику для обработки доступа к базе данных. Чтобы сохранить код чистым и модульным, рекомендуется, чтобы логика доступа к базе данных была изолирована в отдельный модуль. В многоуровневой архитектуре этот модуль является DAL.
До сих пор мы не говорили о какой-либо конкретной реализации: только общий принцип, который помещает логику доступа к базе данных в отдельный модуль.
Теперь, как мы можем реализовать этот принцип? Хорошо, один из известных способов реализации этого, в частности с помощью таких сред, как Hibernate, - это шаблон DAO.
Шаблон DAO - это способ генерации DAL, где обычно каждый объект домена имеет свой собственный DAO. Например, Userи UserDao, Appointmentи AppointmentDao, и т. Д. Пример DAO с Hibernate: http://gochev.blogspot.ca/2009/08/hibernate-generic-dao.html .
Тогда что такое шаблон репозитория? Как и DAO, шаблон репозитория также является способом достижения DAL. Основной момент в шаблоне репозитория заключается в том, что с точки зрения клиента / пользователя он должен выглядеть или вести себя как коллекция. Что значит вести себя как коллекция, так это то, что ее не нужно создавать как экземпляр Collection collection = new SomeCollection(). Вместо этого это означает, что он должен поддерживать такие операции, как добавление, удаление, содержание и т. Д. Это суть шаблона репозитория.
На практике, например, в случае использования Hibernate, шаблон репозитория реализуется с помощью DAO. То есть экземпляр DAL может быть одновременно экземпляром шаблона DAO и шаблона репозитория.
Шаблон репозитория не обязательно является чем-то, что строится поверх DAO (как некоторые могут предположить). Если DAO спроектированы с интерфейсом, который поддерживает вышеупомянутые операции, то это экземпляр шаблона репозитория. Подумайте об этом: если DAO уже предоставляют набор операций, подобный коллекции, тогда зачем нужен дополнительный слой поверх него?
Честно говоря, это выглядит как семантическое различие, а не техническое различие. Фраза «Объект доступа к данным» вообще не относится к «базе данных». И, хотя вы могли бы спроектировать его так, чтобы он был ориентирован на базу данных, я думаю, что большинство людей подумали бы сделать это как недостаток дизайна.
Цель DAO - скрыть детали реализации механизма доступа к данным. Чем отличается шаблон репозитория? Насколько я могу сказать, это не так. Сказать, что репозиторий отличается от DAO, потому что вы имеете дело с / возвращаете коллекцию объектов, не может быть правильным; DAO также могут возвращать коллекции объектов.
Все, что я читал о шаблоне репозитория, похоже, опирается на это различие: плохой дизайн DAO против хорошего дизайна DAO (он же шаблон проектирования репозитория).
Репозиторий - это более абстрактный термин, ориентированный на домен, который является частью Domain Driven Design, он является частью дизайна вашего домена и общим языком, DAO - это техническая абстракция для технологии доступа к данным, репозиторий касается только управления существующими данными и фабриками для создания данные.
проверьте эти ссылки:
http://warren.mayocchi.com/2006/07/27/repository-or-dao/ http://fabiomaulo.blogspot.com/2009/09/repository-or-dao-repository.html
Основное отличие состоит в том, что репозиторий обрабатывает доступ к корням агрегата в агрегате, а DAO - к объектам. Поэтому обычно репозиторий делегирует фактическое постоянство совокупных корней DAO. Кроме того, поскольку совокупный корень должен обрабатывать доступ других объектов, ему может потребоваться делегировать этот доступ другим DAO.
DAO предоставляет абстракцию для файлов базы данных / данных или любого другого механизма персистентности, чтобы можно было манипулировать уровнем персистентности, не зная деталей его реализации.
Принимая во внимание, что в классах репозитория несколько классов DAO могут использоваться внутри одного метода репозитория для выполнения операции с «точки зрения приложения». Таким образом, вместо использования нескольких DAO на уровне домена, используйте репозиторий, чтобы сделать это. Репозиторий - это уровень, который может содержать некоторую логику приложения, например: если данные доступны в кеше в памяти, тогда извлекайте их из кеша, в противном случае извлекайте данные из сети и сохраняйте их в кеше в памяти для последующего извлечения.
Репозиторий - это не что иное, как хорошо разработанный DAO.
ORM ориентированы на таблицы, но не DAO.
Нет необходимости использовать несколько DAO в репозитории, поскольку сам DAO может делать то же самое с репозиториями / сущностями ORM или любым поставщиком DAL, независимо от того, где и как машина сохраняется 1 таблица, 2 таблицы, n таблиц, половина таблицы, веб-сервис, таблица, веб-сервис и т. д. Сервисы используют несколько DAO / репозиториев.
Мой собственный DAO, скажем, CarDao имеет дело только с Car DTO, я имею в виду только Car DTO на входе и только возврат DTO автомобиля или наборы DTO автомобиля на выходе.
Так что, как и Repository, DAO на самом деле является IoC для бизнес-логики, позволяющей не запугивать интерфейсы сохраняемости стратегиями привязанности или наследием. DAO как инкапсулирует стратегию персистентности, так и обеспечивает интерфейс персистентности, связанный с доменом. Репозиторий - это просто другое слово для тех, кто не понял, что такое четко определенный DAO.
Попытайтесь выяснить, подходит ли DAO или шаблон репозитория к следующей ситуации: представьте, что вы хотели бы предоставить единый API доступа к данным для постоянного механизма для различных типов источников данных, таких как RDBMS, LDAP, OODB, репозитории XML и плоские файлы.
Также, если интересно, обратитесь к следующим ссылкам:
http://www.codeinsanity.com/2008/08/repository-pattern.html
http://blog.fedecarg.com/2009/03/15/domain-driven-design-the-repository/
http://devlicio.us/blogs/casey/archive/2009/02/20/ddd-the-repository-pattern.aspx
в очень простом предложении: существенным отличием является то, что репозитории представляют коллекции, в то время как DAO располагаются ближе к базе данных, часто гораздо более ориентированные на таблицы.
В рамках Spring есть аннотация, называемая репозиторием, а в описании этой аннотации есть полезная информация о репозитории, которая, я думаю, будет полезна для этого обсуждения.
Указывает, что аннотированный класс представляет собой «Репозиторий», первоначально определенный Domain-Driven Design (Evans, 2003) как «механизм для инкапсуляции хранения, извлечения и поиска, который эмулирует коллекцию объектов».
Команды, реализующие традиционные шаблоны Java EE, такие как «Объект доступа к данным», могут также применять этот стереотип к классам DAO, хотя следует позаботиться о том, чтобы понять различие между объектом доступа к данным и репозиториями в стиле DDD, прежде чем делать это. Эта аннотация является стереотипом общего назначения, и отдельные команды могут сузить свою семантику и использовать по мере необходимости.
Аннотированный таким образом класс подходит для трансляции Spring DataAccessException при использовании вместе с PersistenceExceptionTranslationPostProcessor. Аннотированный класс также разъясняется в отношении его роли в общей архитектуре приложения с целью инструментария, аспектов и т. Д.
IRepositoryинтерфейс. Вы бы хотели, чтобы ваш репозиторий использовал DAO в своей реализации. Помните, что DAO будет объектом для каждой таблицы, в то время как репозиторий почти всегда должен будет использовать несколько DAO для создания одного объекта. Если вы обнаружите, что это не тот случай, когда вашему репозиторию и сущности требуется доступ только к одной таблице, то вы, скорее всего, создаете анемичный домен.