В MVVM трябва ли ViewModel или моделът да внедри INotifyPropertyChanged?

Бих казал точно обратното, винаги поставям моя INotifyPropertyChanged в моя ViewModel - наистина не искате да замърсявате модела си с доста специфична за WPF функция като INotifyPropertyChanged, тези неща трябва да стоят в ViewModel.

Сигурен съм, че другите не биха се съгласили, но това е начинът, по който работя.

Категорично не съм съгласен с концепцията, че моделът не трябва да прилага INotifyPropertyChanged. Този интерфейс не е специфичен за потребителския интерфейс! Той просто информира за промяна. Наистина, WPF силно използва това, за да идентифицира промените, но това не означава, че е UI интерфейс. Бих го сравнил със следния коментар: „Гумата е аксесоар за автомобил“. Разбира се, но велосипеди, автобуси и т.н. също го използват. В обобщение, не приемайте този интерфейс като UI нещо.

Като каза това, това не означава непременно, че вярвам, че моделът трябва да предоставя известия. Всъщност, като основно правило, моделът не трябва да прилага този интерфейс, освен ако не е необходимо. В повечето случаи, когато към клиентското приложение не се изпращат сървърни данни, моделът може да е остарял. Но ако слушам данни от финансовия пазар, тогава не виждам защо моделът не може да внедри интерфейса. Като пример, какво ще стане, ако имам логика, различна от потребителския интерфейс, като например услуга, която, когато получи цена Bid или Ask за дадена стойност, издава предупреждение (напр. чрез имейл) или прави поръчка? Това може да е възможно чисто решение.

Въпреки това има различни начини за постигане на нещата, но аз винаги бих твърдял в полза на простотата и избягването на излишъка.

Какво е по-добре? Дефиниране на събития в колекция или промени в свойствата на модела на изгледа и разпространението им в модела или изгледът да актуализира вътрешно модела (чрез модела на изглед)?

В крайна сметка, когато видите някой да твърди, че „не можете да направите това или онова“, това е знак, че той не знае какво говори.

Наистина зависи от вашия случай и всъщност MVVM е рамка с много проблеми и тепърва ще виждам обща реализация на MVVM навсякъде.

Иска ми се да имам повече време да обясня многото разновидности на MVVM и някои решения на често срещани проблеми - предимно предоставени от други разработчици, но предполагам, че ще трябва да го направя друг път.

В M-V-VM ViewModel винаги (Моделът не винаги) прилага INotifyPropertyChanged

Разгледайте шаблона/комплекта с инструменти за проект M-V-VM от http://blogs.msdn.com/llobo/archive/2009/05/01/download-m-v-vm-project-template-toolkit.aspx. Той използва DelegateCommand за командване и трябва да бъде страхотен начален шаблон за вашите M-V-VM проекти.

Мисля, че MVVM е много лошо наименуван и наричането на ViewModel ViewModel кара мнозина да пропускат важна характеристика на една добре проектирана архитектура, която е DataController, който контролира данните, независимо кой се опитва да ги докосне.

Ако мислите за View-Model като повече за DataController и внедрявате архитектура, при която вашият DataController е единственият елемент, който докосва данните, тогава никога няма да докосвате данните директно, а винаги ще използвате DataController. DataController е полезен за потребителския интерфейс, но не непременно само за потребителския интерфейс. Той е за бизнес слой, UI слой и т.н.

DataModel -------- DataController ------ View
                  /
Business --------/

В крайна сметка получавате модел като този. Дори бизнесът трябва да докосва данните само с помощта на ViewModel. Тогава главоблъсканицата ви просто изчезва.

Зависи как сте внедрили вашия модел. Моята компания използва бизнес обекти, подобни на CSLA обектите на Lhotka, и използва широко INotifyPropertyChanged в целия бизнес модел.

Нашата машина за валидиране разчита до голяма степен на уведомяването, че свойствата се променят чрез този механизъм и той работи много добре. Очевидно, ако използвате различна реализация, различна от бизнес обекти, където уведомяването за промени не е толкова критично за операцията, може да имате други методи за откриване на промяна във вашия бизнес модел.

Имаме и View Models, които разпространяват промените от Модела, където е необходимо, но самите View Models слушат основните промени в Модела.

Съгласен съм с отговора на Paulo, прилагането на INotifyPropertyChanged в модели е напълно приемливо и дори се предлага от 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.

Бих казал във вашия ViewModel. Не е част от модела, тъй като моделът не зависи от потребителския интерфейс. Моделът трябва да бъде „всичко ОСВЕН бизнес агностик“

Но понякога (както в тази презентация текст на връзката) моделът е услуга, която доставя на приложението някои данни онлайн и след това трябва да внедрите известие, че са пристигнали нови данни или данните са се променили с помощта на събития...

Мисля, че всичко зависи от случая на използване.

Когато имате прост модел с много свойства, можете да го накарате да внедри INPC. Под просто имам предвид, че този модел изглежда по-скоро като POCO.

Ако вашият модел е по-сложен и живее в домейн на интерактивен модел - модели, препращащи към модели, абонирани за събития на други модели - да имате моделни събития, внедрени като INPC, е кошмар.

Поставете се в позиция на някаква моделна единица, която трябва да си сътрудничи с някои други модели. Имате различни събития, за които да се абонирате. Всички те са изпълнени като INPC. Представете си тези манипулатори на събития, които имате. Една огромна каскада от клаузи if и/или клаузи switch.

Друг проблем с INPC. Трябва да проектирате приложенията си така, че да разчитат на абстракция, а не на имплементация. Това обикновено се прави с помощта на интерфейси.

Нека да разгледаме 2 различни реализации на една и съща абстракция:

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 може да се промени“.

Мисля, че отговорът е доста ясен, ако искате да се придържате към MV-VM.

вижте: http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

В модела MVVM изгледът капсулира потребителския интерфейс и всяка логика на потребителския интерфейс, моделът на изгледа капсулира логиката и състоянието на представяне, а моделът капсулира бизнес логиката и данните.

„Изгледът взаимодейства с модела на изгледа чрез обвързване на данни, команди и събития за уведомяване за промяна. Моделът на изгледа запитва, наблюдава и координира актуализациите на модела, преобразувайки, валидирайки и агрегирайки данни, ако е необходимо за показване в изгледа.“

Внедряването на INPC в модели може да се използва, ако моделите са ясно изложени в ViewModel. Но като цяло ViewModel обвива моделите е негови собствени класове, за да намали сложността на модела (което не трябва да е полезно за обвързването). В този случай INPC трябва да бъде внедрен в ViewModel.

Използвам интерфейса INotifyPropertyChange в модел. Всъщност промяната на свойството на модела трябва да се задейства само от потребителския интерфейс или външен клиент.

Забелязах няколко предимства и недостатъци:

Предимства

Нотификаторът е в бизнес модела

1. Що се отнася до домейна, това е правилно. То трябва да реши кога да вдигне и кога не.

Недостатъци

Моделът има свойства (количество, процент, комисионна, обща цена). Totalfriegh се изчислява с помощта на количество, процент, промяна на комисионната.

1. При зареждане на стойности от db, общото изчисление на превоза се извиква 3 пъти (количество, тарифа, комисионна). Трябва да е веднъж.

2. Ако скоростта, количеството са зададени в бизнес слоя, отново се извиква нотификатор.

3. Трябва да има опция за деактивиране на това, вероятно в основния клас. Разработчиците обаче може да са забравили да направят това.

Просто използвайте INotifyPropertyChange във вашия изгледмодел, а не в модела,

моделът обикновено използва IDataErrorInfo за обработка на грешките при валидиране, така че просто запазете своя ViewModel и сте точно на пътя на MVVM.

Да предположим, че референцията на обекта във вашия изглед се промени. Как ще уведомите всички свойства да бъдат актуализирани, за да показват правилните стойности? Извикването на OnPropertyChanged според вас за всички свойства на обекта е боклук от моя гледна точка.

Така че това, което правя, е да позволя на самия обект да уведомява всеки, когато стойност в свойство се промени, и според мен използвам свързвания като Object.Property1, Object.Property2 и други. По този начин, ако просто искам да променя обекта, който в момента се поддържа в моя изглед, просто правя OnPropertyChanged("Object").

За да избегна стотици известия по време на зареждането на обекти, имам частен булев индикатор, който задавам на true по време на зареждане, който се проверява от OnPropertyChanged на обекта и не прави нищо.

Обикновено ViewModel ще имплементира INotifyPropertyChanged. Моделът може да бъде всичко (xml файл, база данни или дори обект). Моделът се използва за предоставяне на данните на модела на изгледа, който се разпространява в изгледа.

вижте тук

imho мисля, че viewmodel прилага INotifyPropertyChange и моделът може да използва известие на различно "ниво".

например с някаква документна услуга и документен обект имате събитие documentChanged, което моделът на изглед слуша, за да изчисти и възстанови изгледа. В модела на изглед за редактиране имате промяна на свойствата за свойствата на документа, за да поддържате изгледите. Ако услугата прави много с документа при запазване (актуализиране на дата на промяна, последен потребител и т.н.), лесно получавате претоварване от Ipropertychanged събития и просто documentchanged е достатъчно.

Но ако използвате INotifyPropertyChange във вашия модел, мисля, че е добра практика да го предавате във вашия изгледмодел, вместо да се абонирате за него директно във вашия изглед. В този случай, когато събитията се променят във вашия модел, трябва само да промените модела на изглед и изгледът остава недокоснат.

Всички свойства, които са обвързани с моя изглед, са в моите ViewModel(s). Следователно те трябва да внедрят интерфейса INotifyPropertyChanged. Следователно изгледът получава всички промени.

[Използвайки инструментариума MVVM Light, им позволих да наследят от ViewModelBase.]

Моделът поддържа бизнес логиката, но няма нищо общо с изгледа. Следователно няма нужда от интерфейс INotifyPropertyChanged.