только для справок в будущем:
function getscreenresolution()
{
window.alert("Your screen resolution is: " + screen.height + 'x' + screen.width);
}
DAO
является абстракцией постоянства данных .
Repository
является абстракцией коллекции объектов .
DAO
будет считаться ближе к базе данных, часто на основе таблицы.
Repository
будет считаться ближе к Области, имея дело только с Совокупными Корнями.
Repository
могут быть реализованы с использованием DAO
, но вы бы не сделали обратное.
Кроме того, Repository
обычно является более узким интерфейсом. Это должен быть просто набор объектов с Get(id)
, Find(ISpecification)
, Add(Entity)
.
Такой метод, как Update
, подходит для DAO
, но не для Repository
- при использовании Repository
изменения в сущностях обычно отслеживаются отдельным UnitOfWork.
Кажется распространенным видеть реализации, называемые Repository
, которые действительно больше похожи на DAO
, и, следовательно, я думаю, что есть некоторая путаница в разнице между ними.
Репозиторий - это более абстрактный термин, ориентированный на домен, который является частью доменного дизайна, он является частью дизайна вашего домена и общего языка, 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.
ORM ориентированы на таблицы, но не DAO.
Нет необходимости использовать несколько DAO в репозитории, так как сам DAO может делать то же самое с репозиториями / сущностями ORM или любым поставщиком DAL, независимо от того, где и как машина сохраняется 1 таблица, 2 таблицы, n таблиц, половина таблица, веб-сервис, таблица, веб-сервис и т. д. Сервисы используют несколько DAO / репозиториев.
Мой собственный DAO, скажем, CarDao имеет дело только с Car DTO, я имею в виду, только Car DTO на входе и только возвращают car DTO или car DTO на выходе.
Так же, как и Repository, DAO на самом деле является IoC для бизнес-логики, позволяющей не запугивать интерфейсы сохраняемости из-за стратегий переноса или наследования. DAO как инкапсулирует стратегию персистентности, так и обеспечивает интерфейс персистентности, связанный с доменом. Репозиторий - это просто другое слово для тех, кто не понял, что такое четко определенный DAO.
DAO и шаблон репозитория являются способами реализации уровня доступа к данным (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 или шаблон репозитория наиболее подходящим для следующей ситуации: представьте, что вы хотели бы предоставить унифицированный 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 предоставляет абстракцию для файлов базы данных / данных или любого другого механизма персистентности, так что уровень персистентности можно манипулировать, не зная деталей его реализации.
В то время как в классах репозитория несколько классов DAO могут использоваться в одном методе репозитория для выполнения операции с точки зрения приложения. Таким образом, вместо использования нескольких DAO на уровне домена, используйте репозиторий, чтобы сделать это. Репозиторий - это слой, который может содержать некоторую прикладную логику , например: если данные доступны в кеше в памяти, тогда извлекайте их из кеша, в противном случае извлекайте данные из сети и сохраняйте их в кеше в памяти для последующего получения .
в очень простом предложении: существенное отличие состоит в том, что репозитории представляют коллекции, в то время как 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 более гибким / универсальным, в то время как репозиторий более специфичен и ограничен только типом.
Честно говоря, это выглядит как семантическое различие, а не техническое различие. Фраза «Объект доступа к данным» вообще не относится к «базе данных». И, хотя вы могли бы спроектировать его так, чтобы он был ориентирован на базу данных, я думаю, что большинство людей посчитают это недостатком дизайна.
Цель DAO - скрыть детали реализации механизма доступа к данным. Чем отличается шаблон репозитория? Насколько я могу сказать, это не так. Сказать, что репозиторий отличается от DAO, потому что вы имеете дело с / возвращаете коллекцию объектов, не может быть правильным; DAO также могут возвращать коллекции объектов.
Все, что я читал о шаблоне репозитория, похоже, опирается на это различие: плохой дизайн DAO против хорошего дизайна DAO (он же шаблон проектирования репозитория).