스키너 컨트롤러를 사용하는 N 계층 도메인/뷰 모델에 대한 모범 사례

Question

우리는 과체중 컨트롤러에서 전체 도메인으로 로직을 이동시켜 마른 컨트롤러를 생성하려고합니다.

View Model을 채울 수 있도록 컨트롤러에 올바른 정보를 제공 할 수있는 도메인 모델을 작성하는 방법에 대한 질문이 있습니다.

우리의 데이터베이스 먼저 솔루션은 다음과 같은 계층을 가지고

:

UI

저장소

• 도메인

• (현재 웹 프로젝트는 MVC 사용) •

• 데이터 액세스 계층 - 엔티티 프레임 워크

? 데이터 (SQL Server를 가리키는 데이터베이스 프로젝트)

보기 엔티티의 데이터 양이 다른보기 모델이 필요한 다양한 뷰가 있다고 가정 해 보겠습니다.

• OrderBasic보기 모델 - 단지 ID, 제목 및 OrderWithCustomer보기 모델 • 날짜

- 고객 엔티티에서 위의 플러스 고객의 이름과 전화 번호

• OrderWithLines 모델보기 - OrderBasic 및 해당 정보가 포함 된 Order Line 목록

• 기타

,210

우리의 옵션을 것 같다 :

1. 을 다음과 유사 도메인 모델을 만듭니다. 도메인 모델이 개별 뷰의 요구 사항에 영향을받으며 코드를 복제하기 때문에이 둘 모두가 옳지 않은 것처럼 보입니다.

2. 필요할 수있는 모든 정보가있는 각 엔터티에 대해 하나의 도메인 모델을 만듭니다. 일부보기의 경우 성능에 좋지 않은 것처럼 보입니다. 필요한 정보보다 많은 정보가 채워지고 클라이언트로 전송됩니다.

3. as 2 그러나 필수 입력란 만 채우는 별도의 매개 변수화 된 도메인 메소드가 있습니다. 이것은 더 효과적 일 수 있지만 모델이 불완전하다는 것을 의미합니다.

더 좋은 방법이 있습니까? 모범 사례는 무엇입니까?

감사합니다.

크리스.

Answer 1

도메인 모델은 서로 통신하고 비즈니스 요구를 수행하고 비즈니스 규칙을 캡슐화하는 상호 연결된 객체의 그래프입니다. 비즈니스 워크 플로 및/또는 계산/알고리즘을 캡슐화하는 Domain Services도 있습니다.

도메인 개체를 모델링 할 때 비즈니스 이외의 다른 것에 관심을 두지 않아야합니다. 규칙입니다. DB에 대해 신경 쓰지 않아야합니다.

응용 프로그램의 유스 케이스를 캡슐화 한 Application Layer 구조가 누락되었습니다 (응용 프로그램을 변경하면 유스 케이스도 변경된다고 생각할 수 있습니다).

애플리케이션 계층 (MVC 컨트롤러를 포함한다)를 UI와 도메인 층 사이 앉고 일부 유스 케이스를 실현할 엔티티 및/또는 도메인 서비스를 조정한다.

응용 프로그램 계층에서 일부 DTO 객체 (DB 자체의 엔티티가 아닙니다!)를 반환하고 해당 DTO의 정보를 매우 UI 친화적 인보기 모델 객체로 변환합니다 (예 : HTML에서 단순한 직접 데이터 바인딩 만 할 수 있습니다).

여러 프로젝트에서 동일한 아키텍처 (어쩌면 작은 조정)를 구현했는데 모델 상태 유효성 검사가 더 이상없는 스키니 컨트롤러와 App 레이어에 대한 호출 1 개, DTO와 뷰 사이의 일부 접착제 코드 등의 좋은 결과가있었습니다. 모델.

여기에 대해 이야기 할 내용이 많이 있으며 사용자의 환경 및 비 기능 요구 사항에 따라 접근 방식이 다를 수 있으므로 실제로 수행중인 작업과 사용자의 특정 작업에 이해가되는 경우 항상 새보기를 유지하십시오. 상태.

P. 여기서 좋은 지침을 찾을 수 있습니다 (의존성 규칙 기억). http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html