2009-07-22 2 views
1

수정 된 BISDM 버전을 기반으로 여러 데이터베이스 엔티티에 대한 RESTful 서비스를 만들고 있습니다. 이러한 엔티티들 중 일부는 아래에 나타낸 바와 같이 룩업 테이블을 관련있다 :리포지토리 패턴을 구현할 때 조회 값/테이블이 자체 리포지토리를 가져야합니까?

Snippet of modified BISDM schema

가 I 데이터 지속성/회수 간의 분명한 구분을 제공하는 저장소 패턴을 사용하기로했다; 그러나 엔티티와는 대조적으로 조회가 저장소에 어떻게 표시되어야하는지 잘 모르겠습니다.

룩업은 자체 저장소 인터페이스를 가져야하며 연관된 엔티티와 하나를 공유하거나 일반 ILookupRepository 인터페이스가 있어야합니까?

잠시 동안 이러한 조회는 읽기 전용입니다. 그러나 서비스를 통해 조회를 편집 할 수있는 시간이 있습니다. 덧붙여서이 질문은 look-up tables & RESTful web services에 관한 또 다른 질문과 관련이 있습니다.

답변

3

아니요. 저장소는 엔터티 수준 개념이 아닌 도메인 모델 개념을 나타내야하며 확실히 데이터베이스 수준이 아니어야합니다. 도메인의 특정 구성 요소 (예 : Spaces)로 수행하고자하는 모든 작업을 생각해보십시오.

할 일 중 하나는 GetSpaceCategories()입니다. Spaces를 다루는 사람은 다른 저장소를 인스턴스화 할 필요없이 Space 범주에 대한 액세스를 원할 것이므로 이것은 확실히 Spaces 저장소에 포함되어야합니다.

제네릭 리포지토리는 상당히 비생산적입니다. 유틸리티 클래스와 같은 저장소를 처리하면 보통 복잡한 작업이 두 저장소를 모두 인스턴스화해야한다는 것을 사실상 보장합니다.

+0

이 방법을 사용하면 UpdateSpaceCategory (SpaceCategory spaceCategory) 및 DeleteSpaceCategory (string id)도 ISpaceRepository에 올 바르게 표시됩니까? –

+0

. 저장소의 목적은 기본 데이터 액세스를 숨기는 것입니다. 데이터베이스 계층을 전환하려면 나머지 프로그램에서 여전히 저장소에서 GetCategories() 또는 UpdateCategory()를 호출해야합니다. 변경 사항은 저장소 소비자에게 투명하게 적용됩니다. – womp

관련 문제