여러 엔터티가있는 뷰를 저장하는 MVC3 모범 사례

Question

ViewModel 패턴과 Entity Framework의 리포지토리 패턴을 사용하는 MVC3 응용 프로그램이 제공됩니다.

각각 여러 엔터티로 구성된 만들기 및 업데이트보기가있는 경우 데이터를 저장하는 가장 좋은 방법은 무엇입니까?

각 엔티티의 데이터를 해당 리포지토리와 함께 저장하는 추상화 된 서비스 계층을 사용하여 날짜를 저장해야합니까? 아니면 저장 프로 시저를 사용하여 리포지토리에 데이터를 저장해야합니까?

나는 제안이나 권장 사항에 대해 공개하고 있습니다.

미리 감사드립니다.

Answer 1

DDD/CQRS 방식이 가장 적합한 경우 중 하나입니다. 간단히 말해, 특정 동작 (집계)을 모델링하는 비즈니스 개체가 있습니다. 명확한 경계가있는 Aggregate Root (AR)라고 불리는 하나의 개체가 있습니다. 저장하고 싶을 때 전체 AR을 저장소로 보내면 모든 것을 트랜잭션으로 저장합니다.

워크 플로

사용자는 뷰 모델을 통해 데이터를 전송합니다. 컨트롤러는 저장소에서 AR을 검색하거나 새로운 AR을 작성합니다. 입력 데이터는 대개 AR 메서드를 통해 AR에 매핑됩니다. AR이 데이터 또는 그 결과가 발견되면 일부 비즈니스 규칙을 위반하면 예외가 발생합니다 (기본 유효성 검사가 이미 asp.net mvc에 의해 자동으로 수행되었다고 가정합니다).

모든 것이 정상이면 컨트롤러는 AR을 repo로 전송 한 다음 AR을 EF 엔티티에 매핑 한 다음 저장합니다.

이 내용은 간단히 설명하겠습니다. 물론, 실제로는 약간 다르게 구현 하겠지만 개념은 동일합니다. 중요한 부분은 모든 데이터를 AR에 보내어 관계를 처리하는 방법을 알게되는 것입니다.

중요 포인트 AR이 REPO에 도착 후에 내가 EF 언급 한

참고. 즉, AR은 EF 엔티티와 전혀 관련이 없으며 완전히 분리되어 실제로 비즈니스 모델을 제공합니다. 모델이 업데이트 된 후에 만 ​​EF가 레포 내에 있으며 EF는 레포의 구현 세부 사항이므로주의해야합니다. 레포는 관련 EF 엔티티로 AR 데이터를 전송 (기본적으로 매핑) 한 다음 엔티티를 저장합니다.

비즈니스 (도메인) 모델과 지속성 모델 (EF 엔티티)을 명확하게 구분해야합니다. 비즈니스 규칙을 처리하는 데 EF를 사용하지 말고, db에서 데이터를 응시하거나 검색하는 데에만 사용하십시오. EF는 RDBMS 액세스만을 추상화하여 가상 OOP 데이터베이스로 사용합니다.

ViewModel 패턴을 언급했습니다. MVC를 사용할 때마다 ViewModels를 사용하고 있습니다. 다시 한번, EF 엔티티를 ViewModels로 사용하지 않는 것이 트릭입니다. 뷰에 적합한 '멍청한'뷰 모델을 사용하십시오. VM 부분을 직접 반환하는 특수 쿼리 저장소를 통해 VM을 채 웁니다. repo는 EF 엔티티를 쿼리 한 다음 간단한 DTO 인 VM 비트를 반환합니다. 데이터를 표시 할 때 유효성 검사 및 비즈니스 규칙이 필요 없기 때문입니다.

나는 레이어와 특히 각 레이어의 모델을 구분하는 것이 좋습니다.업데이트 작업을 위해 복잡한 작업 (도메인 모델)을 사용하여 작업을 수행 한 다음 리포지토리를 통해 자신의 상태 만 EF로 전송합니다. 물건을 읽으려면 EF를 쿼리하고 VM에 맞는 간단한 DTO를 반환하십시오.

이것은 CQRS가 실제로하는 것입니다. 단일 모델에 다른 책임 (쓰기 및 읽기)을 맞추려고하지 마십시오.