ORM을 사용할 때 CQS(명령어 쿼리 분리)는 어떻게 구현됩니까?

Question

CQS 아키텍처 패턴의 기본 원칙은 쿼리와 명령을 고유한 경로로 분리하는 것입니다.이상적으로는 지속성 저장소를 읽기/쓰기로 분할할 수 있지만 제 경우에는 정규화된 단일 데이터베이스가 있습니다.

ORM(내 경우에는 NHibernate)을 사용하고 있다면 명령을 실행할 때 ORM이 사용되는 것이 분명합니다.그러나 사용자 화면의 데이터(DTO)를 형성하기 위해 실행해야 하는 다양한 쿼리는 어떻습니까? CQS의 쿼리 측면을 수행할 때 ORM을 버리는 것이 일반적인 관행입니까?

쿼리와 DTO 예측을 어디에서 구현해야 합니까?바로 ADO.NET(데이터 판독기, dtos, 데이터 테이블, 저장 프로세스)?일부 쿼리는 매우 독특하며 모든 것을 하나로 모으기 위해 많은 조인이 필요합니다.쿼리에 대해 데이터베이스를 비정규화하고 싶지는 않지만 뷰(가난한 사람의 비정규화)를 만들 수는 있습니다.

Answer 1

CQS는 DDD 아키텍처 패턴을 의미한다고 가정합니다. CQRS, 엄밀히 말하면 전통적인 것은 아닙니다. CQS 원칙.

나는 여전히 읽기 전용 모델에 NHibernate를 사용할 것입니다.미래 및 다중 쿼리, 게으른/열심히 로딩 등과 같은 많은 장점이 있습니다.DB 채팅을 최적화합니다.또한 UI에서 사용자가 기본적으로 where 절을 변경할 수 있도록 허용하는 경우 ORM을 사용하여 쿼리를 작성하는 것이 더 쉬울 것입니다.

읽기 전용 모델을 기술적으로 처리하는 방법과 관련하여 엔터티를 표시할 수 있습니다. 불변 NHibernate와 함께.모든 읽기 모델 엔터티를 변경 불가능으로 표시하면 됩니다.또한, 나는 NHibernate에서 예측을 업데이트할 수 없다고 생각하므로 이는 읽기 전용 모델로 사용할 수 있는 또 다른 옵션입니다(100% 확실하지 않으므로 내가 틀렸다면 누군가 나를 정정해 주십시오).

추악하거나 불가능한 NH 매핑에 관하여:NH는 뷰와 저장 프로시저에 매핑할 수 있으므로 필요할 때 활용하면 좋을 것 같습니다.SQL은 여전히 ​​동적이기 때문에 뷰는 읽기 전용 시나리오의 저장 프로시저보다 약간 더 유연할 수 있습니다.그러나 이러한 평면화된 구조에 대해 읽기/쓰기가 필요한 경우 저장 프로시저에 매핑하겠습니다.

Answer 2

궁극적으로, 아이디어는 쿼리 채널을 가장 쉽게 구축하고 유지 관리하는 모든 것을 사용해야한다는 것입니다. 더 이상 업데이트, 비즈니스 규칙 시행, 데이터 무결성 유지 또는 대부분의 부하 처리에 대해 걱정할 필요가 없습니다 (대부분). 따라서 이전에는 테이블에 없었던 많은 옵션을 자유롭게 선택할 수 있습니다.

그러나 nhibernate는 여전히 좋은 옵션이 될 수 있습니다 ... 더 이상 자동 기본값이 아닙니다 (때로는 명령 쪽입니다).

우리는 Castle Active Record (후드 아래에서 Nhibernate를 기반으로 함)를 사용하기로 선택했습니다. 주로 수업에서 테이블을 생성하는 멋진 기능이 있기 때문입니다. 여기에 우리의 워크 플로가 있기 때문에 이것은 우리에게 매우 적합합니다. 첫째, 우리는 뷰 모델 클래스를 만듭니다. 이 수업은 전적으로 견해의 요구를 위해 형성됩니다. 그런 다음 해당 ViewModel을 Castle Active Record 속성으로 표시합니다. 그런 다음 Active Record에 쿼리 데이터베이스에서 해당 클래스의 해당 테이블을 생성하도록 요청합니다. 이것은 ViewModel 클래스를 제공하는 쿼리 데이터베이스 테이블을 빠르게 얻는 가장 빠르고 부드러운 방법입니다. 자동 생성은 테이블이 존재하는 유일한 이유는보기를 제공하는 것입니다.

Answer 3

우리는 명령 부품에 ef를 사용하고 쿼리 체인의 경우 똑바로 ado.net => dtos를 사용하고 있습니다. 장점 :

1) SQL 쿼리를 최적화하고 ORM 레이어로 추상화되지 않은 고급 DB 스토어 기능을 사용하는 기능

2) 오버 헤드가 적습니다

그러나 우리는 까다로운 부품 (검색)에 대해서만 분리를 사용하고 있으며 나머지는 공통 엔티티 프레임 워크 모델에 의존합니다.

Answer 4

데이터베이스를 읽는 데 다른 접근 방식을 사용할 필요는 없습니다. 데이터베이스 업데이트. CQS는 단순히 데이터 저장소를 업데이트하는 명령이 데이터 저장소에서 상태를 읽는 쿼리와 분리되어야한다고 말합니다.

Nhibernate를 사용하여 데이터 저장소에서 읽을 수 있지만 데이터 액세스를 캡슐화하기 위해 두 가지 클래스를 작성하여 명확하게 만들 수 있습니다. 한 클래스에는 데이터 저장소를 읽는 방법 (쿼리)이 있고 다른 클래스는 데이터 저장소에 명령 (추가, 업데이트, 삭제)을 발행하는 메소드가 있습니다.

피하려고하는 것은 데이터베이스에서 메시지를 얻은 다음 데이터베이스에서 읽은대로 메시지를 표시하는 메소드입니다. 이것은 두 가지 다른 방법 호출이어야합니다. 상태를 변경하지 않고 동일한 방법에서 값을 반환해서는 안됩니다.

Answer 5

나는 Orm의 독서와 쓰기를 위해 별도의 것을 유지하고 싶다.

nhibernate 명령의 경우 - 내 도메인 모델을 아름답게 맵핑합니다

dapper.net 쿼리의 경우 - 쿼리가 너무 복잡한 경우 DTO를 아름답게 맵핑하고 장관을 허용합니다.

그들은 Han Solo와 Chewbacca와 같은 완벽한 커플입니다.