생성, 업데이트, 가져 오기, 삭제와 같은 기존 뷰에 따라 하나의 고객 엔티티에 대해 여러 개의 뷰 모델이 있습니다. 이러한 뷰 모델은 엔터티와 동일한 속성을 75 %까지 공유합니다.하나의 엔티티를 하나의 뷰 모델 또는 많은 뷰 모델에 매핑하십시오.
모든 고객 뷰 모델을 하나의 큰 뷰 모델로 병합해야합니까?
그래서 하나의 엔티티에서 항상 하나의 뷰 모델과 길로 매핑해야합니다. 지금 생각하지 못한 특정 시나리오에 대한 유연성의 단점이 있습니까?
장기적으로 각 뷰 모델에 포함 된 데이터는 유사하거나 동일 할 수 있지만 의도가 다르므로 장기적으로는 별도로 유지하는 것이 좋습니다. 예를 들어 ViewModel 작성 및 업데이트는 확실히 유사하지만 몇 가지 중요한 차이점이 있습니다. 첫째, Create 뷰 모델은 대개 엔티티의 ID를 가지고 있지 않으며 이해가되지 않으므로 혼동을 줄 수 있습니다. 둘째, 애플리케이션이 부분 업데이트를 지원하는 경우 업데이트 ViewModel은 엔티티 전체가 아닌 기존 엔티티에 대한 변경 사항 모음 일 수 있습니다.
DRY을 위해 노력하는 경우 전체 ViewModel 클래스를 공유하는 것 이외의 방법으로 재사용을 달성 할 수 있습니다. 대신 재사용 가능한 작은 구성 요소를 만들고 상속 대신 구성으로 재사용 할 수 있습니다. 코드를 추론하기가 더 어렵기 때문에 모든 요구 사항을 충족시키기 위해 단일 ViewModel 클래스를 강제 변환하려고하면 버그가 발생합니다. 여러 번, 간단한 복사 & 붙여 넣기는 OOP가 제공하는 것보다 잘 수행됩니다.
한편, 설명대로 ViewModels를 분할하면 각 ViewModel이 목적에 정확히 부합하고 불필요한 속성이 없는지 확인할 수 있으므로 코드 기반이 분명해집니다. 반면에, 유지 보수 할 코드가 더 많다는 것을 의미합니다. 엔티티를 변경하면 여러 ViewModel에 변경 사항이 적용될 수 있습니다.
반면에 하나의 큰 ViewModel 접근 방식은 기본적으로 정확히 반대되는 장점과 단점을 갖고 있지만 ViewModels는 목적에 맞지 않습니다.
정말로 옳고 그른 대답은 여기에 없습니다. 각 접근법의 장단점을 너무 가늠하고 무엇이 가장 잘 될 것인지 결정하십시오.
한 가지 방법은 Create/Update를위한 하나의 ViewModel, Retrieve와 Delete를위한 하나의 ViewModel을 만드는 것입니다. Create/Update는 매우 유사 할 것입니다.
당신을위한 또 다른 대부분의 OO 옵션은 좋은 오래된 상속에있다 : (그것에서 상속) 하나 개의 클래스 MyVM 조치에 공통 기능을 정의하고이를 확장하면 다른 작업에 맞는 볼 : MyVMEdit, MyVMDelete, MyVMCreate,`MyVMList '.
이것은 두 가지 세계에서 가장 좋습니다. 한 번만 유지 관리하고 모든보기에 정확하게 맞게 확장합니다.
수학이 아니므로 취할 수있는 모든 접근 방식으로 작업을 완료 할 수 있습니다.하지만 ... 때때로 우리는 우리의 뿌리에서 너무 멀리 멀리 옮겼습니다 :) 순수하고 좋은 오래된 객체 지향 접근법.
어떤 이유로 든 상속 (또는 확장)에 문제가있는 경우 MyVM<Action> 모델 내에 MyVM 부분을 포함시키고 동일한 수준의 추상화/기능 균형을 얻을 수 있습니다.
평상시처럼 - 올바른 작업에 적합한 도구.
희망이 도움이 될 것입니다.
내가 잘못하면 나를 수정하십시오 MVVM의 ViewModel에 대한 질문입니까 – HatSoft