2

최근에 DDD 프로젝트를 리팩토링하고 있습니다. 내 저장소 계층을 볼 때. 내 저장소에 IQueryable < T>를 반환했습니다. 당황스럽고 ReQueryable < T>를 리포지토리 계층의 내 DDD 프로젝트 저장소에서 반환해야합니까? 나는 대개 저장소 디자인에 IQueryable 형식을 반환합니다. 그러나 오늘 나는 이것과 반대되는 생각을 발견했다. article 나는 그것을 이해할 수 없다!Drec의 저장소에서 IQueryable <T>을 반환해야합니까?

+0

리포지토리 계층에서 무엇을 반환해야합니까? – doublnt

+0

'IEnumerable' 또는'IReadOnlyList'가 더 적절합니다. – guillaume31

답변

4

IQueryable을 반환하면 도메인 계층에서 소비자 계층으로 누설되는 도메인 정보를 허용합니다. 그것은 도메인 객체가 빈혈이되어 모든 행동이 다른 레이어로 이동하는 위험을 증가시킵니다.

IQueryable을 반환하는 것이 매우 편리하지만 코드가 더 단순해진다 고 생각하면 그것은 환상에 불과합니다. 프로젝트가 성장할 때마다 IQueryable은 코드를 진흙탕의 큰 공으로 변형 시키며 도메인 코드는 모든 곳에 분산되어 있습니다. 저장소를 최적화하거나 다른 저장소 (예 : sql에서 nosql)로 영구 보존을 변경할 수 없습니다.

+0

Em, Repository Layer에서 무엇을 반환해야합니까? 그리고 'Specification Patten'을 사용하는 것이 좋은 방법이라는 것을 알았습니다. – doublnt

+0

나는 왜이 대답이 받아 들여지는지 이해할 수 없다. – jannagy02

+0

@ jannagy02 더 정확하게 이해하지 못하겠습니까? –

1

아마 그렇게해서는 안됩니다.

저장소의 역할은 멀리 추상적 인 지속성 세부 사항뿐만 아니라, 또한 프로세스에 필요한 자들을 정의하는 explicit query contract 도메인에 1 명령 제공 할 수 있습니다.

리포지토리에서 반환 된 내용을 추가로 필터링/변환해야한다고 생각되면 리포지토리의 계약에 포함되어야하는 명시 적 쿼리를 캡처하지 못할 가능성이 큽니다.

이렇게 계약을하면 쿼리 클라이언트는 자신의 의도를 표현하고 더 쉽게 최적화 할 수 있습니다.

1. 요즘에는 쿼리를 위해 CQRS 원칙과 by-bass 도메인 모델을 적용하는 것이 일반적입니다. 이 시나리오에서 저장소를 통과하는 유일한 쿼리는 명령을 처리하는 데 필요한 쿼리입니다. 그러나 어떤 방식 으로든이 접근 방식을 사용하도록 강요받지는 않으므로 원하는 경우 리포지토리가보고 쿼리를 수행 할 수 있습니다.