저장소는 실제로 무엇을해야합니까?

많은 리포지토리 패턴을 들었지만 리포지토리가 실제로 무엇을 해야하는지 이해하지 못했습니다. "리포지토리가 실제로 무엇을해야하는지"라고 말할 때 주로 어떤 방법을 제공해야하는지에 관심이 있습니다. 예를 들어, 저장소가 실제로 CRUD 메소드를 제공해야합니까, 아니면 다른 종류의 메소드를 제공해야합니까?

즉, 리포지토리에 비즈니스 로직이 포함되어야합니까, 아니면 단순히 데이터 저장소와 통신하고 저장 또는로드 할 엔터티를 관리하는 로직이 포함되어야합니까?

또한 리포지토리는 집계의 지속성 단위라고 들었습니다. 하지만 어때요? 이것이 실제로 어떻게 작동하는지 이해하지 못합니다. IRepositoryCRUD 메서드를 포함하는 인터페이스 가 하나만 있어야한다고 생각한 다음, 모든 엔터티에 대해 구현에는 데이터 저장소에서 이러한 유형을 저장하고 검색하는 논리 만 포함됩니다.

저장소 개념을 기반으로하는 Spring Data Framework 에서 좋은 예를 볼 수 있습니다 .

여기에서 리포지토리는 데이터 저장소 만 처리하며 비즈니스 로직은 거의 포함하지 않습니다 (서비스 계층 전용). 예를 들어, 디자인을 살펴보면 CRUDRepository 인터페이스가있어 엔티티를 생성, 파괴 및 복구하는 메소드를 제공합니다 (다른 것들 중에서). PagingAndSortingRepository 도 있습니다. PagingAndSortingRepository 에는 정확하게 정렬, 결과 정렬 등을위한 추가 기능이 추가되어 있습니다.

따라서이 프레임 워크는 좋은 저장소 디자인을 연구하기에 좋은 장소 일 것입니다.

내가 아는 한 Spring Data Framework에서 구현 된 많은 개념은 Domain-Driven Design : Tackling Complexity in the Heart of Software 라는 훌륭한 책에서 나온 것입니다. 이 책에는 리포지토리 디자인 전용 섹션이 있습니다.

사본을받는 것을 고려할 수 있습니다.

이 책에서 발췌 한 작은 내용은 다음과 같습니다.

REPOSITORY 패턴은 이러한 솔루션을 캡슐화하고 모델 포커스를 다시 가져 오는 간단한 개념적 프레임 워크입니다.

REPOSITORY는 특정 유형의 모든 객체를 개념 집합 (일반적으로 에뮬레이션)으로 나타냅니다. 보다 정교한 쿼리 기능을 제외하고는 컬렉션처럼 작동합니다. 적절한 유형의 오브젝트가 추가 및 제거되고 REPOSITORY 뒤의 기계가 오브젝트를 삽입하거나 데이터베이스에서 삭제합니다. 이 정의는 초기 수명주기에서 끝까지 AGGREGATES의 근본에 대한 액세스를 제공하는 일관된 책임 세트를 수집합니다.

클라이언트는 클라이언트가 지정한 기준 (일반적으로 특정 속성의 값)에 따라 오브젝트를 선택하는 조회 메소드를 사용하여 REPOSITORY에서 오브젝트를 요청합니다. REPOSITORY는 요청 된 오브젝트를 검색하여 데이터베이스 쿼리 및 메타 데이터 맵핑의 메커니즘을 캡슐화합니다. REPOSITORIES는 클라이언트가 요구하는 기준에 따라 객체를 선택하는 다양한 쿼리를 구현할 수 있습니다. 또한 몇 가지 기준을 충족하는 인스턴스 수와 같은 요약 정보를 반환 할 수도 있습니다. 또한 일부 숫자 속성의 일치하는 모든 개체에 대한 총계와 같은 요약 계산을 반환 할 수도 있습니다.

REPOSITORY는 클라이언트로부터 큰 부담을 덜어주었습니다. 이제는 간단하고 의도를 드러내는 인터페이스와 대화하고 모델 측면에서 필요한 것을 요청할 수 있습니다. 이 모든 것을 지원하려면 복잡한 기술 인프라가 많이 필요하지만 인터페이스는 단순하고 개념적으로 도메인 모델에 연결됩니다.

따라서:

전역 액세스가 필요한 각 유형의 객체에 대해 해당 유형의 모든 객체에 대한 메모리 내 컬렉션의 환상을 제공 할 수있는 객체를 만듭니다. 잘 알려진 글로벌 인터페이스를 통해 액세스를 설정하십시오.

데이터 저장소에서 데이터의 실제 삽입 또는 제거를 캡슐화 할 개체를 추가 및 제거하는 방법을 제공하십시오. 일부 기준에 따라 객체를 선택하고 속성 값이 기준을 충족하는 완전히 인스턴스화 된 객체 또는 객체 모음을 반환하는 방법을 제공하여 실제 스토리지 및 쿼리 기술을 캡슐화합니다. 실제로 직접 액세스해야하는 AGGREGATE 루트에 대해서만 저장소를 제공하십시오. 클라이언트가 모델에 집중하여 모든 객체 스토리지를 위임하고 저장소에 액세스하십시오.

직접적인 CRUD 인터페이스 나 비즈니스 로직을 제공하지 않아야합니다. 비즈니스 로직과 데이터베이스 사이를 중재합니다. 인터페이스는 비즈니스 로직 용어로되어 있어야하지만 비즈니스 로직 프리미티브처럼 비즈니스 로직 자체를 수행해서는 안됩니다. 예를 들어 이메일 시스템을 만들려고한다면 사용자와 메시지가 있습니다. 리포지토리는 사용자 및 메시지에 대한 기본 CRUD 작업을 제공하지만 GetUsersNewMessages (user) 또는 GetSearchedMessages (user, searchTerms)와 같은 메시지의 필터링 된보기도 제공합니다.

아이디어는 저장소가 스토리지 구현 방식을 숨기고 데이터에 빠르고 유연하게 액세스 할 수있는 깔끔한 인터페이스를 제공한다는 것입니다. 작업을 기본 수준의 백킹 스토어에 가장 적합한 방법으로 구현할 수있는 유연성을 가지기보다는 수행해야 할 상황에 대해 높은 수준으로 유지하십시오.