Architecture-center: ProductsCommandHandler (CQRS)와 ProductRepository (기존 아치)의 차이점은 무엇입니까?

에 만든 2019년 11월 15일 · 5코멘트 · 출처: MicrosoftDocs/architecture-center

안녕하세요,
CQRS에이 기사를 작성해 주셔서 감사합니다. 구현이 어떻게 생겼는지 이해하려고 노력 중이며 예제를 살펴 보았습니다. 예제에 제공된 샘플 리포지토리 코드는 이름 지정 규칙을 제외하고 일반적으로 리포지토리를 작성하는 방법과 매우 유사합니다. 예를 들어, 아래에 제공된 저장소가 ProductsCommandHandler 와 동일하다고 생각하며 일반적으로 추가 할 GetProduct 가 여기에 없다는 것이 한 가지 차이점 일 것입니다. 내가 여기에없는 것을 설명해 주시겠습니까?

public class ProductRepository {
  void AddNewProduct(Product newProduct) {
    ...
  }
  void RateProduct(int productId, int userId, int rating) {
    var product = repository.Find(productId);
    if (product != null)
    {
      product.RateProduct(userId, rating);
      repository.Save(product);
    }
  }
}

문서 세부 정보

⚠ 이 섹션을 편집하지 마십시오.

아이디 : 0c0ec92e-c237-f3a6-1835-f2078486dcb3
버전 독립적 ID : f597c9a2-f18f-3722-57f9-acd535472b0b
콘텐츠 : CQRS (명령 및 쿼리 책임 분리) 패턴-클라우드 디자인 패턴
콘텐츠 출처 : docs / patterns / cqrs.md
서비스 : 아키텍처 센터
하위 서비스 : 클라우드 기반
GitHub 로그인 : @ dragon119
Microsoft 별칭 : pnp

Pri1 architecture-centesvc assigned-to-author cloud-fundamentalsubsvc product-question triaged

출처

martinmthomas

👍1

가장 유용한 댓글

@martinmthomas 사실 명령 핸들러는 저장소가 아닙니다. 저장소를 사용합니다.

명령 처리기는 "적합한 경우 실제 명령을 처리"하기위한 것입니다. 이 예에서 ProductsCommandHandler 클래스는 생성자에서 IRepository<Product> 를받습니다.

사용자가 제품 5555를 별 4 개로 평가한다고 가정 해 보겠습니다.

사용자에게 인터페이스가 표시됩니다. 웹 페이지 (로컬 .exe 프로그램 등이 될 수 있음, 웹 사이트를 상상해 보겠습니다)를 가정 해 보겠습니다.
사용자가 버튼을 클릭합니다. 이것이 {"product":"5555","stars":4} 데이터와 함께 route / rate로가는 AJAX POST를 트리거한다고 가정 해 봅시다.
POST 경로에는 컨트롤러가 있습니다. 이 컨트롤러는 POST 호출에서 발생하는 "쓰기"작업과 연결됩니다.
고전적인 접근 방식의 컨트롤러는 고전적인 제품 저장소를로드하고 제품 5555를로드합니다. 그런 다음 제품에 "별 4 개 등급이 지정되었습니다"라고 말하고 저장합니다.
이 접근 방식에서 컨트롤러는 RateProduct 명령을 빌드하고 제품 5555, 별표 4를 채 웁니다. 예제에서는 누가 등급을 매기는지도 채 웁니다.
이 순간 컨트롤러는 쓰기 모델에 "명령을 보냅니다". 여기에는 두 가지 옵션이 있습니다. 명령 핸들러를 호출하거나 큐에 넣습니다.
대기열이 없다고 가정합니다. 그런 다음 컨트롤러에서 CommandHandler 를 가져오고 (아마도 종속성 주입에 의해) 명령을 여기에 배치합니다. h.Handle (c); 여기서 c는 RateProduct 명령입니다.
대기열이 있다고 가정합니다. 그런 다음 컨트롤러에서 대기열을 가져오고 (아마도 종속성 주입으로) 명령을 대기열에 넣습니다. q.Queue (c);
이 마지막 경우 큐의 리스너는 큐에서 명령을 가져와 대신 명령 핸들러를 호출합니다.
thirs 옵션 (권장)으로 컨트롤러는 명령이 동 기적으로 처리되는지 (처리기 가져 오기) 또는 비동기 적으로 (대기열 가져 오기) 처리되는지를 선택하지 않지만 명령 버스를 사용하는 "일반적인 접근 방식"을 사용해야합니다. 배치됩니다. 명령 버스가 b라고 말하면 b.Send (c); 여기서 c는 RateProduct 명령입니다.
이 세 번째 방법을 사용하면 버스 끝에 명령 처리기를 배치하고 "버스에서 명령을 가져 와서 대기열에 배치"하도록 미들웨어를 구성 할 수 있습니다.

따라서 3 가지 옵션 : a) 핸들러 가져 오기, b) 큐 가져 오기, c) 버스를 가져 와서 핸들러 또는 큐에 명령을 보낼지 결정하도록합니다.

어떤 방법을 사용하든간에 ... "클래식 저장소"의 주요 차이점은 컨트롤러에서 저장소 자체를 호출하지 않는다는 것입니다. 컨트롤러는 "엔티티를 관리하는 방법"(클래식 저장소)을 알지 못하지만 "엔티티에 대한 INTENTS OF DOING THINGS를 관리하는 방법"(명령 처리기)을 알고 있습니다.

그런 다음 이름에서 알 수 있듯이 인 텐트로 전송 된 어딘가 (html 웹 컨트롤러, API 컨트롤러, 명령 줄 등)에서 "명령을 처리"하는 것은 명령 처리기이며 CommandHandler입니다. (쓰기 측에 속하는) 해당 명령으로 수행 할 작업을 결정합니다.

예를 들어, CommandHandler는 저장소를 사용하여 제품을 가져오고, 상태를 설정하고, 저장 (예제에서와 같이) 할 수 있지만 이벤트 로그에 기록하고 요소를 트리거하여 읽기 측을 업데이트하고 외부 커넥터를 트리거하는 등의 작업을 수행 할 수도 있습니다.

제품 및 해당 컨트롤러를 별표 표시 / 평가 시스템이 배치되거나 저장되는 "위치"에 대한 AGNOSTIC으로 평가하는 사용자의 작업 기반 UI입니다. 시스템을 처음부터 디자인하고 Product 클래스에 예제와 같이 RateProduct () 메서드가 이미 포함되어 있다고 가정 해보십시오. 좋은.

하지만 ... 제품에 "오래된"접근 방식을 사용하는 레거시 시스템이 있다면 어떨까요? "모델"(예 : Business Mind)에는 제품에 대한 "등급"이 없습니다. 대신 마케팅 담당자는 기존 제품에 등급을 "추가"하고 싶지만 모든 회사는 이것이 "외부적인 것"이라는 데 동의합니다. 제품 저장소를 사용 하시겠습니까? 아니면 이미 작동하고 완전히 테스트 된 제품 및 ProductRepository를 "만지지"않도록 다른 도우미 스토리지를 사용할 수 있습니까?

명령을 사용하면 쓰기 컨트롤러에 신경 쓰지 않습니다. 웹, API 및 CLI는 모두 "명령"을 명령 처리기에 (직접, 대기열을 통해 또는 차례로 처리기 또는 대기열로 라우팅하는 명령 버스를 통해) 전송하고 잊어 버립니다. 그런 다음 명령 처리기는 소스 코드의 중앙 집중식 및 작은 지점에서 "RateProductCommand"로 수행 할 작업을 결정합니다. 이렇게하면 응용 프로그램 코드에서 처리되는 방식이 분리되어 조작성이 향상됩니다.

그런 다음 핸들러는 ProductRepository 또는 "제품 등급"을 저장하는 다른 접근 방식을 사용하는 것이 적합한 지 결정합니다.

그래서 대답하려면 :

CommandHandler => 엔티티 트와 관련이 없습니다. "사용자의 의도"를 처리합니다 (결국 엔티티를 변경하는 것이 될 수 있습니다. 따라서 대부분의 명령 처리기는 저장소를 사용합니다).
저장소 => 특정 엔티티에 대한 실제 저장소.

도움을 드리겠습니다.
자비.

xmontero 에 2020년 01월 18일

👍5

모든 5 댓글

@martinmthomas 귀하의 질문에 감사드립니다! 적절한 업데이트를 검토하고 제공 할 것입니다.

KetanChawda-MSFT 에 2019년 11월 15일

@MikeWasson 여기에 어떤 생각?

KetanChawda-MSFT 에 2019년 11월 15일

AB # 160217- 신고 해 주셔서 감사합니다.이 문제는 검토 중입니다.

absheik 에 2020년 01월 06일

@martinmthomas 사실 명령 핸들러는 저장소가 아닙니다. 저장소를 사용합니다.

명령 처리기는 "적합한 경우 실제 명령을 처리"하기위한 것입니다. 이 예에서 ProductsCommandHandler 클래스는 생성자에서 IRepository<Product> 를받습니다.

사용자가 제품 5555를 별 4 개로 평가한다고 가정 해 보겠습니다.

사용자에게 인터페이스가 표시됩니다. 웹 페이지 (로컬 .exe 프로그램 등이 될 수 있음, 웹 사이트를 상상해 보겠습니다)를 가정 해 보겠습니다.
사용자가 버튼을 클릭합니다. 이것이 {"product":"5555","stars":4} 데이터와 함께 route / rate로가는 AJAX POST를 트리거한다고 가정 해 봅시다.
POST 경로에는 컨트롤러가 있습니다. 이 컨트롤러는 POST 호출에서 발생하는 "쓰기"작업과 연결됩니다.
고전적인 접근 방식의 컨트롤러는 고전적인 제품 저장소를로드하고 제품 5555를로드합니다. 그런 다음 제품에 "별 4 개 등급이 지정되었습니다"라고 말하고 저장합니다.
이 접근 방식에서 컨트롤러는 RateProduct 명령을 빌드하고 제품 5555, 별표 4를 채 웁니다. 예제에서는 누가 등급을 매기는지도 채 웁니다.
이 순간 컨트롤러는 쓰기 모델에 "명령을 보냅니다". 여기에는 두 가지 옵션이 있습니다. 명령 핸들러를 호출하거나 큐에 넣습니다.
대기열이 없다고 가정합니다. 그런 다음 컨트롤러에서 CommandHandler 를 가져오고 (아마도 종속성 주입에 의해) 명령을 여기에 배치합니다. h.Handle (c); 여기서 c는 RateProduct 명령입니다.
대기열이 있다고 가정합니다. 그런 다음 컨트롤러에서 대기열을 가져오고 (아마도 종속성 주입으로) 명령을 대기열에 넣습니다. q.Queue (c);
이 마지막 경우 큐의 리스너는 큐에서 명령을 가져와 대신 명령 핸들러를 호출합니다.
thirs 옵션 (권장)으로 컨트롤러는 명령이 동 기적으로 처리되는지 (처리기 가져 오기) 또는 비동기 적으로 (대기열 가져 오기) 처리되는지를 선택하지 않지만 명령 버스를 사용하는 "일반적인 접근 방식"을 사용해야합니다. 배치됩니다. 명령 버스가 b라고 말하면 b.Send (c); 여기서 c는 RateProduct 명령입니다.
이 세 번째 방법을 사용하면 버스 끝에 명령 처리기를 배치하고 "버스에서 명령을 가져 와서 대기열에 배치"하도록 미들웨어를 구성 할 수 있습니다.

따라서 3 가지 옵션 : a) 핸들러 가져 오기, b) 큐 가져 오기, c) 버스를 가져 와서 핸들러 또는 큐에 명령을 보낼지 결정하도록합니다.

그런 다음 핸들러는 ProductRepository 또는 "제품 등급"을 저장하는 다른 접근 방식을 사용하는 것이 적합한 지 결정합니다.

그래서 대답하려면 :

도움을 드리겠습니다.
자비.

xmontero 에 2020년 01월 18일

👍5

@xmontero가 언급했듯이 ProductsCommandHandler 및 ProductRepository에는 "has"관계 만 있습니다. ProductsCommandHandler는 ProductApi / Controller와 ProductRepository 간의 인터페이스 역할을합니다. 이 구현은 쿼리와 별도로 명령을 함께 유지하는 데 도움이됩니다. 전통적인 접근 방식에서는 컨트롤러에서 직접 저장소를 사용하여 명령과 쿼리를 함께 실행하므로 다른 인터페이스가 필요하지 않습니다.

명령을 쿼리와 분리하여 유지하는 경우 애플리케이션에 CQRS 디자인 패턴을 적용한 것입니다. 기사에 언급 된 CQRS의 모든 이점을 얻는 방향으로 안내합니다.

learnigility 에 2020년 01월 24일

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Architecture-center: ProductsCommandHandler (CQRS)와 ProductRepository (기존 아치)의 차이점은 무엇입니까?

문서 세부 정보

가장 유용한 댓글

모든 5 댓글

관련 문제