저장소 패턴 : 구성원 목록 작성 전략

Question

저장소 용 CRUD 화면 세트를 작성 중입니다. 구성원 개체는 검색 결과를 생성 할 때처럼 많은 양을 동시에 메모리에로드하지 않을만큼 충분히 큽니다.

"name"과 "id"와 같은 검색 결과가 필요합니다. - 은 기본 데이터베이스를 쿼리 할 수 ​​있습니다.하지만 저장소를 우회하고 싶지 않습니다. 그 가치를 상당 부분 무효로 만들 것입니다.

발견 한 저장소 패턴 인트로 및 자습서는이 시나리오를 다루지 않습니다. 그들은 한 번에 하나의 완전히 채워진 객체를 저장/검색/삭제하는 데 중점을 둡니다.

지연로드 객체의 프록시 패턴에 익숙합니다. 그러나 큰 소년들이 그것을하는 방법입니까? 이 문제에 대해 잘 정립 된 해결책이 있습니까?

Answer 1

DDD로 엄격하게 가면 검색을 통해 완전히 채워진 개체가 반환되어야한다고 생각합니다. 그러나 때로는 규칙을 굴절시켜야합니다.

내가하지 말아야 할 무엇을 말할 수 :

1. 필요한 데이터 만 검색하고 여전히 엔티티 클래스의하지-완전히 채워진 인스턴스를 반환하지 않습니다. 이것은 쉽게 재앙이 될 수 있습니다. 겉으로보기에는 완전히 채워진 엔티티를 반환하는 다른 쿼리 메서드로 끝납니다. 그러나 실제로는 호출 된 쿼리 메서드에 따라 달라집니다. 혼란을 예상하십시오.

2. 지연 초기화 스키마를 롤백하지 마십시오. 그것은 어렵고 오류가 발생하기 쉽습니다. 나는 이것을 한 번 해봤고, 노력의 가치가 없다고 안전하게 말할 수 있습니다.

그럼 남아있는 것은 무엇입니까? 내 투표는 필요한 데이터를 가져 와서 채울 계획 인 필드 만 가진 클래스를 만들고 그 목록을 반환하는 것입니다. 이제 검색 함수를 호출하는 모든 사람들은 실제 데이터의 하위 집합 인 정확히 무엇을 얻고 있는지 알고 있습니다. 전체 엔티티가 필요할 때 데이터베이스를 다시 히트해야합니다.

public class CakeRepository { 
    public List<CakeProjection> getCakesByManufacturer(String manufacturer); 

    public Cake getCake(long id); 

    ... 
} 

public class CakeProjection { 
    private long id; 
    private String cakeName; 

    ... 
} 

Answer 2

리포지토리 인터페이스에서 쿼리를 정의하면 이후의 데이터가 되돌아옵니다.

나는 큰 소년들이 (최대 절전 모드와 같은) ORM 레이어를 사용하고 ORM에 정의 된 쿼리를 전달한다고 생각한다.