MVVM에서 ViewModel 또는 Model이 INotifyPropertyChanged를 구현해야합니까?

필자가 작업 한 대부분의 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에서 모든 객체를 관리해야합니다.

그러나 때로는 (이 프리젠 테이션 링크 텍스트 에서와 같이 ) 모델은 서비스로, 일부 데이터를 온라인으로 응용 프로그램에 제공 한 다음 새로운 데이터가 도착했거나 이벤트를 사용하여 데이터가 변경되었다는 알림을 구현해야합니다 ...

MV-VM을 준수하려면 대답이 분명하다고 생각합니다.

참조 : http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

MVVM 패턴에서보기는 UI 및 모든 UI 논리를 캡슐화하고,보기 모델은 프리젠 테이션 논리 및 상태를 캡슐화하며, 모델은 비즈니스 논리 및 데이터를 캡슐화합니다.

"뷰는 데이터 바인딩, 명령 및 변경 알림 이벤트를 통해 뷰 모델과 상호 작용합니다. 뷰 모델은 모델에 대한 업데이트를 쿼리, 관찰 및 조정하고 뷰에 표시하는 데 필요한 데이터를 변환, 확인 및 집계합니다."

ViewModel에 말하고 싶습니다. 모델이 UI와 무관하므로 모델의 일부가 아닙니다. 모델은 '비즈니스에 관계없이 모든 것'이어야합니다

모델이 ViewModel에 명확하게 노출 된 경우 모델에서 INPC를 구현할 수 있습니다. 그러나 일반적으로 모델을 감싸는 ViewModel은 모델 복잡성을 줄이기 위해 자신의 클래스입니다 (바인딩에는 유용하지 않아야 함). 이 경우 INPC는 ViewModel에서 구현되어야합니다.

INotifyPropertyChange모델 에서 인터페이스를 사용하고 있습니다. 실제로 모델 속성 변경은 UI 또는 외부 클라이언트에서만 실행해야합니다.

몇 가지 장점과 단점을 발견했습니다.

장점

알리미는 비즈니스 모델에 있습니다

1. 구동되는 도메인에 따라 맞습니다. 언제 올릴 것인지 아닌지를 결정해야합니다.

단점

이 모델에는 속성 (수량, 요금, 수수료, 총액)이 있습니다. Totalfrieght는 수량, 요금, 수수료 변경을 사용하여 계산됩니다.

1. db에서 값을로드 할 때 총 frieght 계산을 3 회 (수량, 요율, 수수료)라고합니다. 한 번되어야합니다.

2. 비즈니스 계층에 rate, qty가 지정된 경우 다시 알리미가 호출됩니다.

3. 기본 클래스에서이를 비활성화하는 옵션이 있어야합니다. 그러나 개발자는이 작업을 잊어 버렸습니다.

나는 그것이 모두 유스 케이스에 달려 있다고 생각합니다.

많은 속성을 가진 간단한 모델이있는 경우 INPC를 구현하도록 할 수 있습니다. 간단히 말해서이 모델은 오히려 POCO 처럼 보입니다 .

모델이 더 복잡하고 대화 형 모델 도메인 (모델을 참조하고 다른 모델의 이벤트를 구독하는 모델)에 거주하는 경우 INPC로 구현 된 모델 이벤트를 갖는 것은 악몽입니다.

다른 모델과 공동 작업을 수행해야하는 모델 엔터티의 위치에있게하십시오. 구독 할 다양한 이벤트가 있습니다. 그들 모두는 INPC로 구현됩니다. 가지고있는 이벤트 핸들러를 상상해보십시오. if-clauses 및 / 또는 switch claus의 거대한 캐스케이드.

INPC의 또 다른 문제. 구현이 아닌 추상화에 의존하도록 앱을 설계해야합니다. 이것은 일반적으로 인터페이스를 사용하여 수행됩니다.

동일한 추상화의 두 가지 다른 구현을 살펴 보겠습니다.

public class ConnectionStateChangedEventArgs : EventArgs
{
    public bool IsConnected {get;set;}
}

interface IConnectionManagerINPC : INotifyPropertyChanged
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    bool IsConnected {get;}
}

interface IConnectionManager
{
    string Name {get;}
    int ConnectionsLimit {get;}
    /*

    A few more properties

    */
    event EventHandler<ConnectionStateChangedEventArgs> ConnectionStateChanged;
    bool IsConnected {get;}
}

이제 둘 다 봅니다. IConnectionManagerINPC는 무엇을 알려줍니까? 일부 속성이 변경 될 수 있습니다. 당신은 그들 중 어느 것을 모른다. 실제로 디자인은 IsConnected 만 변경하고 나머지는 읽기 전용이므로 변경됩니다.

반대로 IConnectionManager의 의도는 분명합니다. "IsConnected 속성 값이 변경 될 수 있음을 알려줄 수 있습니다."

그냥를 사용하여 INotifyPropertyChange모델에서의 ViewModel에서가 아니라,

모델은 일반적으로 IDataErrorInfo유효성 검사 오류를 처리하기 위해를 사용 하므로 ViewModel을 유지하면 MVVM 도로에 있습니다.

뷰에서 객체의 참조가 변경되었다고 가정하십시오. 올바른 값을 표시하기 위해 모든 속성을 업데이트하도록 알리는 방법은 무엇입니까? OnPropertyChanged모든 객체의 속성에 대한 당신의 견해를 부르는 것은 내 관점에 쓰레기입니다.

그래서 내가하는 일은 속성의 값이 변경 될 때 객체 자체가 누군가에게 알리도록하고 내 견해 Object.Property1에서 Object.Property2와 같은 바인딩을 사용 하는 것입니다. 그런 식으로 현재 뷰에서 유지 관리되는 객체를 변경하고 싶다면 그냥 수행하십시오 OnPropertyChanged("Object").

객체를로드하는 동안 수백 가지 알림을 피하기 위해 객체에서 확인되고 OnPropertyChanged아무것도하지 않는 로드하는 동안 true로 설정하는 개인 부울 표시기가 있습니다.

일반적으로 ViewModel은을 구현합니다 INotifyPropertyChanged. 모델은 무엇이든 가능합니다 (xml 파일, 데이터베이스 또는 객체). 모델은 데이터를 뷰 모델로 전달하는 데 사용되며 뷰 모델은 뷰로 전파됩니다.

여기를 보아라

imho 나는 viewmodel이 구현 INotifyPropertyChange하고 모델이 다른 "레벨"에서 알림을 사용할 수 있다고 생각합니다 .

예를 들어 일부 문서 서비스 및 문서 객체를 사용하면 뷰 모델이 뷰를 지우고 다시 작성하기 위해 청취하는 documentChanged 이벤트가 있습니다. 뷰 모델 편집에서 뷰를 지원하기 위해 문서의 속성에 대한 속성 변경이 있습니다. 서비스가 문서를 저장할 때 (변경 날짜, 마지막 사용자 등 업데이트) 작업을 많이 수행하는 경우 Ipropertychanged 이벤트를 쉽게 오버로드하고 문서를 변경하기 만하면됩니다.

그러나 INotifyPropertyChange모델에서 사용하는 경우 뷰에서 직접 구독하는 대신 뷰 모델에서 릴레이하는 것이 좋습니다. 이 경우 모델에서 이벤트가 변경되면 뷰 모델 만 변경하면 뷰는 그대로 유지됩니다.

내 뷰에 바인딩 된 모든 속성은 내 ViewModel에 있습니다. 따라서 INotifyPropertyChanged 인터페이스를 구현해야합니다. 따라서보기는 모든 변경 사항을 가져옵니다.

[MVVM Light 툴킷을 사용하여 ViewModelBase에서 상속하게했습니다.]

모델은 비즈니스 로직을 보유하지만 뷰와 관련이 없습니다. 따라서 INotifyPropertyChanged 인터페이스가 필요하지 않습니다.