MVVM에서는 뷰 모델을 뷰에 바인딩해야하는 모든 데이터와 명령을 제공하는 클래스로 생각합니다.MVVM 프로젝트에서 "다른"종류의 뷰 모델 이름은 무엇입니까?
그러나 데이터베이스 엔터티 개체 (예 : Customer)가 있고 데이터 그리드에 사용할 Customer 클래스를 형성하거나 플랫 화하는 클래스를 작성하려고하면 어떻게됩니까? 예를 들어,이 특수 Customer 객체는 TotalOrders 속성을 가지며 실제로는 Order 엔티티 집합의 조인을 사용하여 계산됩니다.
제 질문은이 특수 문자를 Customer 클래스라고합니다. 다른 상황에서 나는 그것을 CustomerViewModel이라고 부기를 원하지만이 같은 뷰 모델 개념은 MVVM 프로젝트에서 혼란 스러울 것이라고 생각합니다. 너는 무엇을 제안 하겠는가?
나는 당신이 원래의 생각에 맞았다 고 생각합니다. "View Model"클래스는 도메인 모델의 데이터 객체를 노출하여 이러한 모델 객체를보다 쉽게 소비하고 관리 할 수있는 클래스입니다.
체크 아웃 http://en.wikipedia.org/wiki/Model_View_ViewModel
는 따라서 Customer 및 Order 클래스는 "모델"의 조각입니다. 당신이 묘사하고 CustomerViewModel을 호출하는 것은 사실 "View Model"이며 WPF 페이지/컨트롤은 "View"입니다.
이름 지정과 관련하여 ... 원하는대로 이동하십시오! 하지만 원래의 아이디어는 CustomerViewModel입니다. 또는보기의 이름에 조금 더 근접한 이름을 지정하십시오. 예를 들어, 페이지가 CustomerOrderSummary 페이지 인 경우 CustomerOrderSummaryViewModel입니다.
매우보기 모델이 아닌 List 개체가있는 몇 가지 예제가 있습니다. 고객 모델 개체를 VM 용으로 더 많이 변경 했으므로 CustomerDto로 이름을 지정하거나 포스터의 나머지 부분에 동의하면 CustomerViewModel (CustomerVM)도 좋습니다.
데이터 뷰 모델이라고합니다.
예를 들어, Results_ViewModel을 뷰 모델로 갖는 Results.xaml을 가질 수 있습니다. 결과 페이지에는 그리드가 있으며 그리드의 각 행은 고객입니다. 하지만 당신이 말했듯이, 당신은 'Total Orders'와 같은 속성을 가질 수 있도록 고객을위한 뷰 모델을 원합니다. 이 경우 그리드에는 Customer_DataViewModel 컬렉션이 포함됩니다.
+1. 나는 "DataViewModel"을 좋아한다. Reddog의 대답에 대한 내 의견을 참조하십시오. – devuxer
다른 개념 (즉, 다른 곳으로 보낼 데이터를 나타내는 무언가)을 의미하므로 CustomerDto가 마음에 들지 않습니다. 기본적으로 PresentationModel이라는 용어는 모델 계층에 속하지 않는 속성을 가진 기본 모델 객체를 '제시'하기 때문에 사용됩니다. 필자는 실제로 모델과 PresentationModel을 읽기 전용보기로 변경할 수있는 경우 ViewModel이라는 용어를 사용합니다.
아마도 'CustomerListViewModel'입니까? –
로버트와 동의, 어쩌면 내가 CustomerListItem 또는 CustomerListItemViewModel (나도 알아, 입가 ...) – Josh