여러 집계 루트로보기 모델을 처리하는 방법은 무엇입니까?

StackOverflow https://stackoverflow.com/questions/2020499

문제

현재, 나는 꽤 나쁜 뷰 모델을 얻었습니다.

클래스는 이것 =>처럼 보입니다

 public class AccountActionsForm
    {
        public Reader Reader { get; set; }
        //something...
    }

문제는 독자 유형이 도메인 모델 (SRP 위반)에서 나온다는 것입니다.

기본적으로 디자인 팁을 찾고 있습니다 (예 : 뷰 모델을 입력/출력으로 나누는 것이 좋습니다.) 내보기 모델 마찰이없고 개발자 친화적 인 방법 (예 : 매핑은 컨트롤러 기본 클래스를 사용하여 자동으로 작동해야합니다). ?

Automapper 프레임 워크를 알고 있으며 사용할 것입니다.

그렇다면 다시 한 번 - 적절한보기 모델을 만들려고 할 때 일반적인 gotchas는 무엇입니까? 그것을 구조화하는 방법? 여러 도메인 객체 입력이 필요한 경우 어떻게 매핑이 수행됩니까?

뷰가 1 개 이상의 집계 루트의 데이터가 필요한 경우에 대해 혼란스러워합니다. 라이브러리, 리더, 서지 기록 등과 같은 엔티티가있는 앱을 만들고 있습니다.

내 경우 - 도메인 수준에서는 3 가지 유형을 모두 그룹화하는 것이 의미가 없습니다. LibraryReaderThatHasOrderedSomeBooks 또는 어떤 것도, 그러나 특정 라이브러리의 특정 독자를위한 주문 된 책에 대한 목록을 표시 해야하는보기에는 모두 필요합니다.

그래서 -보기를 만드는 것은 괜찮은 것 같습니다 OrderedBooksList ~와 함께 OrderedBooksListModel 아래에서 모델을 봅니다 LibraryOutput, ReaderOutput 그리고 BibliographicRecordOutput 모델을 봅니다. 또는 더 나은 - OrderedBooksListModel 모델, 그 활용 평평한 기술 그리고 같은 소품이 있습니다 ReaderFirstName, LibraryName 등.

그러나 하나 이상의 입력이 있기 때문에 매핑 문제가 발생합니다.
더 이상 1 : 1 관계가 아닙니다.
그것은 내 도메인 모델이 친절하다는 것을 의미합니까?

그리고 UI 레이어 (즉, 확인 된 탭을 나타내는 ENUM)에 순수하게 살고있는보기 모델 필드는 어떻습니까?

~이다 이것 그런 경우 모두가 무엇을합니까?

 FooBarViewData fbvd = new FooBarViewData();
   fbvd.Foo = new Foo(){ A = "aaa"};
   fbvd.Bar = new Bar(){ B = "bbb"};
   return View(fbvd);

나는 이것을 기꺼이하지 않을 것이다 =>

var fbvd = new FooBarViewData();
   fbvd.FooOutput =  _mapper.Map<Foo,FooOutput>(new Foo(){ A = "aaa"});
   fbvd.BarOutput = _mapper.Map<Bar,BarOutput>(new Bar(){ B = "bbb"});
   return View(fbvd);

많은 글쓰기처럼 보입니다. :)

이것을 읽습니다 현재. 그리고 이것.

확인. 나는이 문제에 대해 많이 생각했고 예 - 다른 추상화 레이어를 추가하는 것은 솔루션처럼 보인다 =>

alt text

그래서 - 내 마음에 이것은 이미 작동합니다. 이제는 약간의 연설을위한 시간입니다.

타이 지미

도움이 되었습니까?

해결책

이 모든 것을 정의하기는 어렵지만 여기에갑니다. 우리는 컨트롤러가 구축하는 내용에서보기가 보는 것을 분리하는 것을 좋아합니다. 보기는 평평하고 뇌-죽음 DTO와 같은 물체를 봅니다. 우리는 이것을보기 모델이라고 부릅니다.

컨트롤러 측면에서, 우리는보기 모델을 빌드하는 데 필요한 내용의 풍부한 그래프를 구축합니다. 이것은 단일 집계 뿌리 일 수 있거나 여러 집계 뿌리의 구성 일 수 있습니다. 이 모든 것들이 함께 프레젠테이션 모델이라고 부르는 것과 결합합니다. 때때로 프레젠테이션 모델은 우리의 지속성 (도메인) 모델이지만 때로는 새로운 객체 일 때가 있습니다. 그러나 실제로 우리가 찾은 것은 복합 프레젠테이션 모델을 구축해야한다면 관련 행동의 자석이되는 경향이 있다는 것입니다.

귀하의 예에서는 ViewFooBarmodel과 ViewFooBarViewModel (또는 ViewFoobarModelDTO)을 만들었습니다. 그런 다음 컨트롤러의 ViewFooBarmodel에 대해 이야기 한 다음 매핑에 의존하여 Automapper를 사용 하여이 중간 모델에서 필요한 것을 평평하게합니다.

다른 팁

오랫동안 대안으로 어려움을 겪은 후 우리에게 새벽이 된 항목이 있습니다. 렌더링 데이터는 데이터 수신과 다릅니다.

우리는 ViewModels를 사용하여 데이터 렌더링을 사용하지만 양식 게시 및 유사한 양식을 통해 데이터를 수신 할 때 ViewModel이 ModelBinding의 개념에 맞게 만들 수 없었습니다. 주된 이유는 브라우저에 대한 왕복이 종종 데이터 손실과 관련이 있기 때문입니다.

예를 들어, ViewModels를 사용하더라도 실제 도메인 객체의 데이터를 기반으로하지만 도메인 객체에서 모든 데이터를 노출 시키지는 않습니다. 이는 브라우저가 게시 한 데이터에서 기본 도메인 객체를 즉시 재구성하지 못할 수 있음을 의미합니다.

대신, 우리는 Mappers와 Repositories를 사용하여 게시 된 데이터에서 전체 도메인 객체를 검색해야합니다.

이것을 깨닫기 전에, 우리는 게시 된 데이터에서 전체 도메인 객체 또는 뷰 모델을 재구성 할 수있는 사용자 정의 모델 바인더를 구현하려고 노력했지만 이제는 별도가 있습니다. 우편 모델 우리가 데이터를 수신하는 방법.

우리는 추상 매퍼와 서비스를 사용하여 우편 모델을 도메인 객체에 매핑 한 다음 필요한 경우 뷰 모델로 돌아갑니다.

그룹에 의미가 없을 수도 있습니다 관련이 없습니다 도메인 객체 또는 서비스로 엔티티 (또는 오히려 리포지토리)가 프레젠테이션 계층으로 그룹화하는 것이 의미가있을 수 있습니다.

특정 애플리케이션에 특히 적합한 방식으로 도메인 데이터를 나타내는 사용자 정의 뷰 모델을 작성하는 것처럼 필요에 따라 사물을 결합한 사용자 정의 프리젠 테이션 계층 서비스를 사용합니다. 이러한 서비스는 주어진 견해를 지원하기 위해 존재하기 때문에 훨씬 더 임시입니다.

종종 우리는이 서비스를 인터페이스 뒤에 숨기므로 구체적인 구현이 원하는 결과를 구성하는 데 필요한 관련없는 주입 도메인 객체를 자유롭게 사용할 수 있도록합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top