DAO (Data Access Objects)와 리포지토리 패턴의 차이점은 무엇입니까? Enterprise Java Beans (EJB3), Hibernate ORM을 인프라로 사용하고 DDD (Domain-Driven Design) 및 TDD (Test-Driven Development)를 설계 기술로 사용하여 애플리케이션을 개발 중입니다.
답변
DAO
데이터 지속성 의 추상화입니다 . 객체 컬렉션의
Repository
추상화입니다 .
DAO
종종 테이블 중심 데이터베이스에 더 가깝게 간주됩니다.
Repository
집합 루트에서만 다루는 도메인에 더 가까운 것으로 간주됩니다.
Repository
의를 사용하여 구현할 DAO
수는 있지만 그 반대의 경우는 없습니다.
또한 a Repository
는 일반적으로 더 좁은 인터페이스입니다. 그것은으로, 단순히 개체의 컬렉션해야한다 Get(id)
, Find(ISpecification)
, Add(Entity)
.
와 같은 메소드 Update
는에 적합 DAO
하지만 a Repository
를 사용 하지 않는 경우 Repository
엔터티 변경은 대개 별도의 UnitOfWork에 의해 추적됩니다.
라는 구현을 참조하는 것이 일반적 보인다 Repository
정말 더의 인 것을 DAO
, 따라서 나는 그들 사이의 차이에 대한 혼란이 있다고 생각합니다.
답변
좋아, 내가 의견에 넣은 것을 더 잘 설명 할 수 있다고 생각한다. :). 따라서 기본적으로 DAO는 리포지토리보다 더 유연한 패턴이지만 둘 다 동일하게 볼 수 있습니다. 둘 다 사용하려면 DAO에서 저장소를 사용하십시오. 아래에 각각 설명하겠습니다.
저장소:
특정 유형의 객체를 저장하는 저장소입니다. 특정 유형의 객체를 검색하고 저장할 수 있습니다. 일반적으로 한 가지 유형의 객체 만 처리합니다. 예 AppleRepository
를 들어 AppleRepository.findAll(criteria)
또는 할 수 있습니다 AppleRepository.save(juicyApple)
. 리포지토리는 도메인 모델 용어 (DB 용어가 아님-데이터가 어디서나 유지되는 방법과 관련이 없음)를 사용하고 있습니다.
리포지토리는 모든 데이터를 동일한 테이블에 저장하지만 패턴에는 필요하지 않습니다. 한 가지 유형의 데이터 만 처리하므로 하나의 기본 테이블 (DB 지속성에 사용되는 경우)에 논리적으로 연결됩니다.
DAO-데이터 액세스 객체 (즉, 데이터에 액세스하는 데 사용되는 객체)
DAO는 데이터를 찾는 클래스입니다 (주로 파인더이지만 일반적으로 데이터를 저장하는 데 사용됨). 이 패턴은 동일한 유형의 데이터를 저장하도록 제한하지 않으므로 관련 객체를 찾고 저장하는 DAO를 쉽게 가질 수 있습니다.
예를 들어 다음과 같은 메소드를 노출하는 UserDao를 쉽게 가질 수 있습니다.
Collection<Permission> findPermissionsForUser(String userId)
User findUser(String userId)
Collection<User> findUsersForPermission(Permission permission)
이들은 모두 사용자 (및 보안)와 관련이 있으며 동일한 DAO에서 지정할 수 있습니다. 리포지토리의 경우에는 해당되지 않습니다.
드디어
두 패턴 모두 실제로는 동일하지만 (데이터를 저장하고 액세스를 추상화하며 도메인 모델에 더 가깝게 표현되고 DB 참조를 거의 포함하지 않음), 사용 방식은 약간 다를 수 있습니다. 좀 더 유연하고 일반적인 반면 리포지토리는 좀 더 구체적이고 유형에만 제한적입니다.
답변
DAO 및 리포지토리 패턴은 DAL (Data Access Layer)을 구현하는 방법입니다. 먼저 DAL부터 시작하겠습니다.
데이터베이스에 액세스하는 객체 지향 응용 프로그램에는 데이터베이스 액세스를 처리 할 논리가 있어야합니다. 코드를 깨끗하고 모듈 식으로 유지하려면 데이터베이스 액세스 논리를 별도의 모듈로 분리하는 것이 좋습니다. 계층 구조에서이 모듈은 DAL입니다.
지금까지 특정 구현에 대해서는 언급하지 않았습니다. 데이터베이스 액세스 로직을 별도의 모듈에 배치하는 일반적인 원칙 만 있습니다.
이제이 원리를 어떻게 구현할 수 있습니까? 글쎄, 특히 Hibernate와 같은 프레임 워크에서 이것을 구현하는 방법 중 하나는 DAO 패턴입니다.
DAO 패턴은 일반적으로 각 도메인 엔터티에 자체 DAO가있는 DAL을 생성하는 방법입니다. 예를 들어 User
와 UserDao
, Appointment
그리고 AppointmentDao
: 하이버 네이트 등으로 DAO의 예 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 디자인 대 좋은 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는 데이터베이스 / 데이터 파일 또는 기타 지속성 메커니즘에 대한 추상화를 제공하여 구현 세부 사항을 몰라도 지속성 계층을 조작 할 수 있습니다.
리포지토리 클래스에서는 단일 리포지토리 메서드 내에서 여러 DAO 클래스를 사용하여 “앱 관점”에서 작업을 수행 할 수 있습니다. 따라서 도메인 계층에서 여러 DAO를 사용하는 대신 리포지토리를 사용하여 완료하십시오. 리포지토리는 다음 과 같은 일부 응용 프로그램 논리를 포함 할 수있는 계층입니다 . 메모리 내 캐시에서 데이터를 사용할 수있는 경우 캐시에서 데이터를 가져 오면 네트워크에서 데이터를 가져 와서 다음 번 검색을 위해 메모리 내 캐시에 저장합니다.