내 데이터베이스는 상대적으로 작으며 8 개의 테이블로 구성되며 각각 5 개 미만의 열이 있습니다. 나는 EF를 사용한다. 단일 리포지토리 클래스를 만들었지 만 지금은 사용하는 것이 올바른 방법이 아닐 수도 있습니다. 내 컨트롤러마다 별도의 저장소 클래스를 사용해야합니까? 내가 제품, 사용자, 유니콘을 가지고 있다고 말하면 모든 저장소와 함께 작동하는 하나의 저장소 클래스를 가질 수 있고 각각의 컨트롤러에서 인스턴스화 할 수 있습니까? 아니면 각각에 대해 별도의 저장소 클래스를 만들어야합니까?단일 또는 다중 저장소 클래스?
DDD의 핵심 개념 중 하나는 집합 루트입니다.이 집합은 관련 엔터티의 전체 집합을 관리하는 데 사용되는 '최상위 수준'엔터티입니다.
예를 들어 소매 시나리오에서 '주문'은 주문 자체, OrderItems (예 : 할인 + Product + Amount + 수정 자) 목록, BillingAddress, ShippingAddress 및 PaymentMethod에 액세스 할 수있는 집계 루트가됩니다 . 그것들 각각은 질서의 범위 밖에서 존재할 아무 이유도없는 질서 자체와 밀접한 관련이 있습니다.
각 집계 루트는 루트 아래 개체의 전체 하위 그래프를 보존하는 책임을 맡은 저장소가 있어야합니다. 위의 예에서 항목을 독립적으로 액세스 할 수있는 OrderItems의 저장소가 필요하거나 필요하지 않습니다. 대신 Orders 및 모든 하위 구성 요소를 단일 단위로 처리하는 단일 OrdersRepository를 구현해야합니다.
특정 도메인 모델에 따라 하나 이상의 리포지토리가 필요할 수 있지만 엔티티 유형 당 하나는 필요하지 않을 수 있습니다. 집합 적 루트를 찾을 때 질문해야 할 핵심 질문은 "이 엔티티는 고유 한 ID 및 수명주기를 갖고 있습니까?"입니다. Orders가 수행 하 G로 OrderItem은 그렇지 않습니다.
엔티티마다 repoistory가 좋다고 생각하지 않습니다. 오히려 서비스마다 리포지토리가 좋다고 생각하면됩니다.
예를 들어, 주 응용 프로그램의 포커스가 사용자 인 경우 CategoriesRepository 또는 CarsRepository를 만들지 않겠습니다.
Think Domain-Driven Design을 염두에두고 프로젝트의 논리 구조를 클래스로만 나누지 않고 모든 도메인과 마찬가지로 모든 작업이 Product과 관련이 있다는 것을 ProductsController 결과적으로 ProductsRepository 내에 있으므로 프로젝트의 일부 측면을 다루는 작업을 갖춘 많은 저장소를 선호합니다.
모든 측면에서 저장소가 필요할 수는 없지만 이것이 사용자가 결정한 사항입니다.
위대한 답변! 유용한 정보를 설명하는 유용한 문서 http://devlicio.us/blogs/casey/archive/2009/02/16/ddd-aggregates-and-aggregate-roots.aspx – GibboK