두 개의 뷰 모델 간 마스터 - 세부 분할 : 취소 명령 논리를 넣을 위치는 어디입니까?

Question

창의 마스터 섹션에 DataGrid가 포함되어 있습니다. 세부 정보 섹션에는 마스터의 DataGrid에서 현재 선택된 레코드를 편집 할 수있는 양식이 표시됩니다. Grid의 SelectedItem은 마스터 VM에 바인딩됩니다. 속성이 변경되면 마스터 VM이 새 EditViewModel을 만들어 속성을 통해 노출합니다. 뷰의 세부 정보 섹션은이 속성을 DataContext로 사용합니다.

취소와 같은 명령을 구현할 때 마스터 또는 상세보기 모델에 넣으시겠습니까?

상세보기 모델은 레코드와의 사용자 상호 작용을 담당합니다. 이 책임에는 삭제가 포함된다고 주장 할 수 있습니다. 반면에 마스터 뷰는 컬렉션과의 사용자 상호 작용을 담당하고 삭제는 컬렉션을 수정하므로 삭제 기능을 배치해야한다고 주장 할 수 있습니다. 내가 요청 된 작업을 수행 할 수있는 서비스 계층을 요청 코드를 구현하는 의미 ", 실행 명령"에 의해 - 명확한 설명 :

는
벤

편집을 주셔서 감사합니다.

Answer 1

두 번째 논의가 처음 것보다 훨씬 강력하다고 생각합니다.

개인적인 견해가 아니라 개인적인 견해로 삭제가 컬렉션의 관심사 인 것 같습니다.

Answer 2

나는 이안의 대답에 동의하지만 나는 개인적으로 UI 로직과 모델 로직 사이의 구분이 중요하다고 생각한다고 덧붙였다.

따라서 삭제가 주로 UI 목록에서 이루어지는 경우 컬렉션 VM에 삭제를 적용하는 것이 좋습니다.

모델 작업 (예 : 데이터베이스에서 레코드 삭제)을 시작하자마자 레코드가이 논리에 적합한 위치 일 것입니다.

또한 모델에 영향을주는 이런 종류의 로직을 도메인 모델과 뷰 모델 밖으로 이동시켜 VM이 가능한 한 많이 UI 로직을 담당하게하고 도메인 모델은 커집니다 비즈니스 논리의 풍부한 표현으로

Answer 3

각 레코드는 자체적으로 만 알고 있습니다. 그것이 컬렉션의 일부라는 사실조차 깨닫지 않아야합니다. 그것은 그 자체로 엔티티입니다. 마스터 VM에는 레코드 모음이 있으므로 수정 작업을 담당해야합니다.

David는 UI 로직과 비즈니스 로직을 분리하는 데 동의합니다. 비즈니스 모델이 변경되면 뷰 모델 코드가 손상되고 DRY 원칙이 계속 유지되므로 스파게티 코드에서 벗어나십시오.