필자가 작업 한 대부분의 MVVM 예제에는 Model 구현 INotifyPropertyChanged이 있었지만 Josh Smith의 CommandSink 예제 에서는 ViewModel이 구현했습니다INotifyPropertyChanged .
나는 여전히 MVVM 개념을인지 적으로 통합하고 있으므로 다음과 같은 경우에 모르겠습니다.
- 작업
INotifyPropertyChanged하려면 ViewModel에을 넣어야합니다 .CommandSink - 이것은 단지 표준의 수차이며 실제로 중요하지 않습니다.
- 항상 Model 구현을 가져야
INotifyPropertyChanged하며 이것은 코드 예제에서 애플리케이션으로 개발 된 경우 수정되는 실수 일뿐입니다.
귀하가 작업 한 MVVM 프로젝트에 대한 다른 사람들의 경험은 무엇입니까?
답변
나는 정반대로 말하고, 항상 INotifyPropertyChanged내 ViewModel에 배치했습니다. 와 같은 상당히 WPF 특정 기능으로 모델을 오염시키고 싶지는 않습니다 INotifyPropertyChanged.
나는 다른 사람들이 동의하지 않을 것이라고 확신하지만 그것이 내가 일하는 방식입니다.
답변
나는 Model이 구현해서는 안된다는 개념에 동의하지 않는다 INotifyPropertyChanged. 이 인터페이스는 UI 전용이 아닙니다! 단순히 변화를 알려줍니다. 실제로 WPF는이를 사용하여 변경 사항을 식별하지만 이것이 UI 인터페이스라는 의미는 아닙니다. 나는 다음과 같은 의견과 비교할 것이다 : ” 타이어는 자동차 액세서리 “. 물론 자전거, 버스 등에서도 사용합니다. 요약하면 해당 인터페이스를 UI로 사용하지 마십시오.
그렇다고해서 반드시 모델이 알림을 제공해야한다고 믿는 것은 아닙니다. 실제로 경험상 모델은 필요하지 않은 한이 인터페이스를 구현하지 않아야합니다. 서버 데이터가 클라이언트 앱으로 푸시되지 않는 대부분의 경우 모델이 오래 될 수 있습니다. 그러나 금융 시장 데이터를 듣고 있다면 왜 모델이 인터페이스를 구현할 수 없는지 알 수 없습니다. 예를 들어, 특정 가치에 대해 입찰 또는 요청 가격을받을 때 경보 (예 : 이메일을 통해)를 발행하거나 주문하는 서비스와 같은 비 UI 논리가있는 경우 어떻게해야합니까? 이것은 가능한 깨끗한 솔루션 일 수 있습니다.
그러나 여러 가지 방법으로 달성 할 수 있지만 항상 단순성을 선호하고 중복성을 피한다고 주장합니다.
더 나은 게 뭐야? 뷰 모델에서 컬렉션 또는 속성 변경 사항에 대한 이벤트를 정의하고이를 모델에 전파하거나 뷰가 모델을 본질적으로 업데이트하도록 (뷰 모델을 통해)?
” 당신이 할 수 없다 “고 주장하는 누군가를 볼 때마다 가장 중요한 것은 그들이 말하는 것을 모르는 신호입니다.
그것은 실제로 귀하의 경우에 달려 있으며 실제로 MVVM은 많은 문제가있는 프레임 워크이며 보드 전체에서 MVVM의 일반적인 구현을 아직 보지 못했습니다.
MVVM의 다양한 특징과 일반적인 문제에 대한 해결책을 설명하는 데 더 많은 시간이 있었으면 좋겠습니다. 대부분 다른 개발자가 제공하지만 다른 시간에해야 할 것 같습니다.
답변
MV-VM에서 ViewModel은 항상 (모두는 아님) 구현합니다. INotifyPropertyChanged
http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx 에서 MV-VM 프로젝트 템플릿 / 툴킷을 확인하십시오 . DelegateCommand명령 에 for를 사용하며 MV-VM 프로젝트를위한 훌륭한 시작 템플릿이어야합니다.
답변
MVVM의 이름이 잘못되어 ViewModel을 ViewModel이라고 부르면 많은 사람들이 잘 설계된 아키텍처의 중요한 기능을 놓치게됩니다.
View-Model을 더 많은 DataController로 생각하고 DataController가 데이터를 다루는 유일한 항목 인 아키텍처를 구현하는 경우 데이터를 직접 만지지 말고 항상 DataController를 사용하십시오. DataController는 UI에 유용하지만 반드시 UI에만 유용하지는 않습니다. 비즈니스 계층, UI 계층 등입니다.
DataModel -------- DataController ------ View
/
Business --------/당신은 이런 모델로 끝납니다. 비즈니스조차도 ViewModel을 사용하여 데이터를 만져야합니다. 그러면 수수께끼가 사라집니다.
답변
모델을 어떻게 구현했는지에 달려 있습니다. 우리 회사는 Lhotka의 CSLA 객체와 유사한 비즈니스 객체를 사용 INotifyPropertyChanged하며 비즈니스 모델 전체에서 광범위하게 사용 합니다.
Google의 유효성 검사 엔진은이 메커니즘을 통해 속성이 변경된다는 알림을받는 데 크게 의존하며 매우 효과적입니다. 변경 알림이 조작에 중요하지 않은 비즈니스 오브젝트 이외의 다른 구현을 사용하는 경우 비즈니스 모델의 변경을 감지하는 다른 방법이있을 수 있습니다.
또한 필요한 경우 모델의 변경 사항을 전파하는 뷰 모델이 있지만 뷰 모델 자체는 기본 모델 변경 사항을 수신하고 있습니다.
답변
Paulo의 답변에 동의합니다 INotifyPropertyChanged. Models 구현 은 완전히 받아 들일 수 있으며 Microsoft에서 제안합니다.
일반적으로이 모델은 뷰에 쉽게 바인딩 할 수있는 기능을 구현합니다. 이는 일반적으로
INotifyPropertyChanged및
INotifyCollectionChanged인터페이스를 통해 속성 및 컬렉션 변경 알림을 지원함을 의미합니다 . 객체 컬렉션을 나타내는 모델 클래스는 일반적으로ObservableCollection<T>클래스 에서 파생되며
INotifyCollectionChanged인터페이스 의 구현을 제공합니다
.
해당 유형의 구현을 원하는지 여부를 결정하는 것은 당신에게 달려 있지만, 기억하십시오-
모델 클래스가 필요한 인터페이스를 구현하지 않으면 어떻게됩니까?
때때로 당신은 구현하지 않는 모델 객체와 함께 작동해야합니다
INotifyPropertyChanged,INotifyCollectionChanged,
IDataErrorInfo, 또는INotifyDataErrorInfo인터페이스를. 이 경우 뷰 모델은 모델 객체를 래핑하고 필요한 속성을 뷰에 노출해야 할 수 있습니다. 이러한 속성의 값은 모델 객체에 의해 직접 제공됩니다. 뷰 모델은 뷰가 데이터에 쉽게 바인딩 될 수 있도록 노출되는 속성에 필요한 인터페이스를 구현합니다.
출처 : http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx
나는 우리가 INotifyPropertyChanged모델에서 구현하지 않은 일부 프로젝트에서 일했으며 이로 인해 많은 문제에 직면했습니다. VM에서 불필요한 속성 복제가 필요했으며 동시에 BL / DL에 전달하기 전에 기본 개체 (업데이트 된 값으로)를 업데이트해야했습니다.
모델 객체 (예 : 편집 가능한 그리드 또는 목록) 또는 복잡한 모델의 컬렉션으로 작업해야하는 경우 특히 문제가 발생합니다. 모델 객체는 자동으로 업데이트되지 않으므로 VM에서 모든 객체를 관리해야합니다.
답변
그러나 때로는 (이 프리젠 테이션 링크 텍스트 에서와 같이 ) 모델은 서비스로, 일부 데이터를 온라인으로 응용 프로그램에 제공 한 다음 새로운 데이터가 도착했거나 이벤트를 사용하여 데이터가 변경되었다는 알림을 구현해야합니다 …
