WPVM의 MVVM에 대한 나의 개념은 애플리케이션의 모든 모델에 대해 ViewModel을 가지고 있다는 것입니다. 즉, 고객 클래스 (엔티티)가 있으면 CustomerViewModel을 갖게됩니다. CustomerViewModel에는 고객을 나타내는 데 필요한 모든 특성이 있습니다. CustomerView 사용자 정의 컨트롤은 Customer 모델에 대한 UI 작성을 담당합니다.MVVM WPF 새로운 엔티티 추가를위한 ViewModels
이제 새로운 고객을 추가한다고 가정 해 보겠습니다. 그래서 FirstName, LastName 등으로 구성된 폼이 있습니다.이 시나리오에서는 ViewModel이 필요합니다. TextBox에서 모든 입력 값을 가져와 Customer 객체를 만든 다음 데이터베이스에 저장하는 것입니다. 이 시나리오에서 ViewModel을 작성해야하는 이유는 무엇입니까?
우선, 모든 것을 "미러링"하는 MVVM의 주된 목적이 아닙니다. 뷰는 사용자 입력을위한 수단을 제공해야하며 데이터베이스 계층에 대한 호출을 처리하지 않아야합니다. ViewModel은 GUI에 구애받지 않는 애플리케이션 백본이어야하며, 분명히 고객 생성을 처리해야합니다.
즉,해야 할 일은 고객 ViewModel뿐만 아니라 고객을 처리하기위한 작업 영역을 나타내는 ViewModel입니다. 생성되는 몇 가지 객체를 저장하려면 해당 작업 공간에 CustomerViewModel이 아닌 새 고객을 만들고 추가 할 수있는 가능성을 추가하십시오. 그렇게하면 고객의 각 관련/필수 속성에 대한 요소가있는 작업 영역의 뷰를 가질 수 있으며, 해당 작업 영역 ViewModel에 추가 된 명령을 호출하면 현재 값을 채울 수 있습니다 (ViewModel에 바인딩 된 데이터) 요소를 고객 모델에 직접 표시합니다.
리팩토링하는 경우 특정 고객 (및 다른 모델) ViewModels을 삭제할 수 있다면 명백한 원인없이 특정 패턴에 맹목적으로 부착하지 않도록하는 것이 좋습니다.
Add에 별도의 ViewModel이있을 필요는 없으며 편집 및 추가 시나리오를 수행해야하는 단일 ViewModel 만 있으면됩니다. 편집 페이지에서 레코드를 삭제할 수있는 경우 ViewModel도 삭제할 수 있어야합니다. ViewModel은 데이터에 관계없이 뷰가 노출하는 기능을 반영해야합니다.
각 모델에 대해 하나의 ViewModel을 재고해야한다고 생각합니다. 저는 ViewModels을 데이터가 삽입 된 정규화 동작이라고 생각합니다. 각 Model 클래스에 대해 ViewModel을 사용하면 조만간 아키텍처 문제가 발생할 것입니다. 애플리케이션을 위에서 아래로 보았을 때, UI가 무엇을 성취하려고하는지, 그리고 거기에서 ViewModel을 얻을 것이고, 결국에는 DataFactory에 접근 할 것이고, ViewModel이 데이터에 어떻게 매핑되는지는 거의 항상 1 대 1이 아닙니다. 가장 단순한보기. 1에서 1로 매핑하려고하면 UI가 좋지 않거나 데이터가 정상적으로 잘되지 않습니다. 우리가 여기
스택입니다 :
ViewModel에는 여러 POCO의 속성이 포함되어 있습니다.
우리는 MoU와 함께 xUnit을 사용하여 StructureMap 및 Unit Test를 통해 DataFactory를 주입합니다.
두 번째 질문에 답하기 위해 별도의보기 만 생성하여 사용자 정의 컨트롤로 드롭했습니다. 하지만 당신은 CRUD ViewModel을 가지고 있어야만 모든 기능을 사용자 친화적 인 방법으로 캡슐화 할 수 있습니다.
감사합니다.
이 VM 추상화의 한 가지 이유는 테스트 가능성 때문입니다. ViewModel을 필요로하는 또 다른 이유는 기본적으로 하나의 컨테이너에있는 여러 모델의 필드를 조합하여 현재보기와 관련성이 높은 데이터 전송 객체이기 때문입니다. VM을 사용하는 또 다른 이유는 WPF 두 가지 방법으로 바인딩 기능을 활용하는 것입니다.
일반 모델 (일반 POCO)을 사용하면 모델이 변경 될 때보기를 업데이트 할 수 있지만 모델이 종속성 속성을 구현하지 않기 때문에 (대개) 모델 업데이트를 활용할 수 없습니다 WPF 컨트롤의 값이 변경 될 때 즉, 핸들러를 수동으로 추가하고이 컨트롤에서이 값을 모델 종류로 복사해야합니다.
비즈니스 모델이 없다고 잠시 생각해 봅시다. 사진 만보기입니다. 시스템의 다른 곳에서 데이터가 무엇을 의미하는지에 대한 지식이 없어도 뷰를 모델링하는 것이 ViewModel입니다.
ViewModel의 목표는 원래의 뷰를 모델링하는 것입니다. 이는 비즈니스 도메인에서 고객의 아이디어를 모델링하는 것과는 다른 목표입니다. 비즈니스 엔터티 당 하나의 ViewModel을 갖게된다면 비즈니스 엔터티 당 하나의 뷰가 생기게되므로 일상적인 데이터 중심 UI가됩니다.
특별한 경우 고객 편집보기를 생각해보십시오. 여기에는 고객 속성에 해당하는 필드가있어 고객에게 직접 바인딩하는 데 자연스럽게 적합합니다. 그러나 고객 객체의 어디에서 "제출"작업이 모델링 되었습니까? '취소'작업은 어디에서 모델링 되었습니까? 필드 X가 목록에서 선택된 열거 형 값인 모델은 어디에서 모델링 되었습니까?
암호는 어떻습니까? 이진 해시 값으로 유지되면 뷰는 텍스트를 해시하는 방법을 알고 있습니까? 시스템의 암호 강도 요구 사항은 어떻게됩니까?
ViewModel은 비즈니스 모델과 UI 사이의 박격포입니다. 그것은 한 사람의 염려를 받아들이고 다른 한 사람의 말로 번역합니다. 위의 모든 문제가 해결되는 시점입니다. ViewModel이 필요 없다고 말하는 것은 그 필요성을 무시하는 것입니다.
그러면 고객 추가를위한 ViewModel을 어떻게 표현 하시겠습니까? 그리고 이후 ViewModel은 서비스/저장소가 데이터베이스에 저장하는 데 사용할 비즈니스 클래스에 값을 전송하기 때문에 어떤 용도로 사용됩니까? – azamsharp
응용 프로그램에 "고객 추가"탭이 있다고 상상해보십시오. 이 탭에는 이름, 주소, 계좌 번호 등의 텍스트 필드가있을 수 있습니다. 예를 들어, "SendToRepository"명령이있는 AddCustomerViewModel을 가질 수 있습니다. 이 중급 VM을 사용하는 이유 중 하나는 1) 그래픽 인터페이스를 애플리케이션 로직과 분리함으로써 앱 로직의 테스트 용이성을 가능하게 할뿐만 아니라 UI 레이어를 거의 변경하지 않아도된다는 것입니다. 2) ViewModel은 UI와 비즈니스 레이어간에 데이터를 적용하고, 코드를 간소화하는 데 사용됩니다 (예 :더 적은 컨버터가 필요함) –
계속 : 3) 종종 View와 ViewModel 사이의 데이터 바인딩은 더 깨끗한 코드를 생성하며, 가장 중요한 것은 애플리케이션 로직이 ViewModels를 변경하고 View 및 해당 리소스를 직접 조작하려고 시도하지 않는 경우 더 나은 코드입니다. –