명령 / 쿼리 분리는 객체를 생성하고 해당 ID를 반환하는 메소드에 적용됩니까?

비즈니스 프로세스를 호출하는 서비스가 있다고 가정 해 봅시다. 이 프로세스는 데이터 계층을 호출하여 데이터베이스에 유형 A의 개체를 만듭니다.

그런 다음 다른 클래스의 데이터 계층을 다시 호출하여 데이터베이스에 B 유형의 인스턴스를 만들어야합니다. 외래 키를 위해 A에 대한 정보를 전달해야합니다.

첫 번째 방법에서는 객체를 만들고 (상태 수정) 단일 방법으로 ID (쿼리)를 반환합니다.

두 번째 방법에는 저장 용 (createA)과 쿼리 용 (getId)의 두 가지 방법이 있습니다.

    public void FirstMethod(Info info)
    {
        var id = firstRepository.createA(info);           
        secondRepository.createB(id);
    }

    public void SecondMethod(Info info)
    {
        firstRepository.createA(info);
        var key = firstRepository.getID(info);
        secondRepository.createB(key);
    }

내 이해에서 두 번째 방법은 명령 쿼리 분리를보다 완전히 수행합니다. 그러나 방금 만든 객체를 얻기 위해 데이터베이스를 쿼리하는 것은 낭비적이고 반 직관적입니다.

그러한 시나리오로 CQS를 어떻게 조정합니까?

두 번째 방법 만 CQS를 따르고 있다면이 경우에 사용하는 것이 바람직합니까?

CQS는 절대 규칙이 아닌 지침입니다. 엄격한 CQS에서 불가능한 활동의 ​​예 는 위키 기사 를 참조하십시오 .

그러나이 경우 CQS를 유지하려는 경우 클라이언트 측 (예 : GUID)에서 ID를 작성하거나 클라이언트가 오브젝트를 작성하기 전에 시스템에서 ID를 요청할 수 있습니다. 객체를 만든 다음 쿼리하는 것보다 (단지 ID 열을 사용하는 것보다 어렵습니다).

개인적으로 ID를 반환하고 CQS가 적합하지 않은 상황 중 하나라고 부릅니다.

예제가있는 또 다른 좋은 기사 : Martin Fowler

방법론을 따르고 나쁜 길로 인도하는 것 같으면 재평가해야합니다.

새로 생성 된 객체의 식별자는 반환 매개 변수로 사용할 수있는 유효한 것으로 나타났습니다. 편리 할뿐만 아니라 "좋은"-코드가 더 좋을 때 알 수 있습니다.

어쨌든 나는 "명령 쿼리 분리"에 익숙하지 않지만 명령 실행에 대한 정보를 반환하지 못하도록 명령을 허용하지 않는다고 의심합니다. 그렇다면 실패합니다. 성공 / 실패는 항상 존재하며 "객체가 정상적으로 생성되었고 ID가 xxx 임"의 "객체가 정상적으로 생성되었다"고 생각하지 마십시오.

두 번째 방법 만이 CQS를 따릅니다.

CQS는 좋은 코딩 관행을 장려하기위한 지침으로 생각합니다. 개발하는 동안 좋은 코딩 방법을 사용하고 나중에이 방법에 리소스에 중요한 코드가 포함되어 있음을 알게되면이를 최적화 할 수 있습니다.

조기 최적화는 모든 악의 근원입니다 :)