Чи повинно ViewModel або Model впроваджувати INotifyPropertyChanged у MVVM?

Більшість прикладів MVVM я працював через мали модель реалізації INotifyPropertyChanged, але в прикладі CommandSink Джоша Сміта знаряддя ViewModelINotifyPropertyChanged .

Я все ще пізнавально складаю концепції MVVM, тож не знаю, чи:

• Ви повинні помістити INotifyPropertyChangedв ViewModel, щоб приступити CommandSinkдо роботи
• Це лише аберація норми, і це насправді не має значення
• У вас завжди має бути реалізація Model, INotifyPropertyChangedі це лише помилка, яка буде виправлена, якби це було розроблено з прикладу коду до програми

Яким був досвід інших щодо проектів MVVM, над якими ви працювали?

Я б сказав зовсім навпаки, я завжди ставлю своє INotifyPropertyChangedна ViewModel - ви дійсно не хочете забруднювати свою модель досить специфічною функцією WPF, наприклад INotifyPropertyChanged, такі речі повинні сидіти у ViewModel.

Я впевнений, що інші не погоджуються, але саме так я працюю.

Я категорично не згоден з концепцією того, що Модель не повинна реалізовувати цю програму INotifyPropertyChanged. Цей інтерфейс не призначений для інтерфейсу! Він просто повідомляє про зміну. Дійсно, WPF активно використовує це для виявлення змін, але це не означає, що це інтерфейс інтерфейсу. Я порівняв би це із наступним коментарем: " Шина - автомобільний аксесуар ". Звичайно, але велосипеди, автобуси тощо користуються цим. Підсумовуючи це, не сприймайте цей інтерфейс як предмет інтерфейсу.

Сказавши це, це не обов'язково означає, що я вважаю, що Модель повинна надавати сповіщення. Насправді, як правило, модель не повинна реалізовувати цей інтерфейс, якщо це не потрібно. У більшості випадків, коли дані про сервер не передаються клієнтській програмі, модель може бути несвіжою. Але якщо слухати дані фінансового ринку, то я не бачу, чому модель не може реалізувати інтерфейс. Як приклад, що робити, якщо у мене є логіка, що не користується інтерфейсом користувача, наприклад, послуга, що коли вона отримує ціну або пропозицію за задане значення, вона надсилає попередження (наприклад, електронною поштою) або розміщує замовлення? Це може бути можливим чистим рішенням.

Однак існують різні способи досягнення речей, але я завжди заперечував би за простоту і уникав зайвих надмірностей.

Що краще? Визначення подій колекції чи зміни властивості моделі перегляду та їх поширення до моделі чи перегляд власне оновлення моделі (через модель перегляду)?

Підсумок кожного разу, коли ви бачите, що хтось стверджує, що " ви не можете цього чи іншого зробити ", це знак, що вони не знають, про що говорять.

Це дійсно залежить від вашого випадку, і насправді MVVM - це рамка з безліччю питань, і я ще не бачу спільної реалізації MVVM в усьому світі.

Мені б хотілося, щоб у мене було більше часу для пояснення багатьох ароматів MVVM та деяких варіантів вирішення загальних проблем - в основному, це надано іншими розробниками, але, мабуть, мені доведеться це зробити в інший раз.

У MV-VM реалізується ViewModel завжди (Модель не завжди) INotifyPropertyChanged

Перегляньте шаблон / інструментарій проекту MV-VM від http://blogs.msdn.com/llobo/archive/2009/05/01/download-mv-vm-project-template-toolkit.aspx . Він використовує DelegateCommandдля командування, і це повинен бути чудовим стартовим шаблоном для ваших проектів MV-VM.

Я думаю, що MVVM дуже погано названий, а виклик ViewModel ViewModel змушує багатьох пропустити важливу особливість добре розробленої архітектури, а саме DataController, який контролює дані, незалежно від того, хто намагається їх торкнутися.

Якщо ви вважаєте модель View як більшу частину DataController і використовуєте архітектуру, де ваш DataController є єдиним елементом, який стосується даних, ви ніколи не торкаєтесь даних безпосередньо, а завжди використовуєте DataController. DataController корисний для інтерфейсу користувача, але не обов'язково лише для інтерфейсу користувача. Він призначений для бізнес-шару, шару інтерфейсу користувача тощо.

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

Ви закінчуєте таку модель. Навіть бізнес повинен торкатися даних лише за допомогою ViewModel. Тоді ваша головоломка просто відходить.

Це залежить від того, як ви реалізували вашу модель. Моя компанія використовує бізнес-об’єкти, схожі на CSLA-об'єкти Lhotka та широко використовує INotifyPropertyChangedвсю бізнес-модель.

Наш механізм перевірки значною мірою покладається на повідомлення про те, що властивості змінюються завдяки цьому механізму, і він працює дуже добре. Очевидно, що якщо ви використовуєте іншу реалізацію, крім бізнес-об'єктів, де повідомлення про зміни не є настільки важливим для операції, у вас можуть бути інші методи виявлення змін у вашій бізнес-моделі.

У нас також є Моделі перегляду, які поширюють зміни від Моделі там, де це потрібно, але самі Моделі перегляду вислуховують основні зміни Моделі.

Я погоджуюся з відповіддю Паулу: реалізація 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.

Особливо ви зіткнетесь з проблемами, якщо вам доведеться працювати зі збиранням об'єктів вашої моделі (скажімо, в редагованій сітці або списку) або складних моделей; об'єкти моделі не оновлюються автоматично, і вам доведеться керувати усім, що знаходиться у вашій машині.

Але іноді (як у тексті цього посилання на презентацію ) модель - це сервіс, який надає додатку деякі дані в Інтернеті, і тоді вам потрібно доповнити повідомлення про те, що нові дані надійшли або дані змінилися за допомогою подій ...

Я думаю, що відповідь цілком зрозуміла, якщо ви хочете дотримуватися MV-VM.

дивіться: http://msdn.microsoft.com/en-us/library/gg405484(v=PandP.40).aspx

У шаблоні MVVM подання інкапсулює інтерфейс користувача та будь-яку логіку інтерфейсу, модель перегляду інкапсулює логіку та стан презентації, а модель інкапсулює бізнес-логіку та дані.

"Перегляд взаємодіє з моделлю перегляду за допомогою прив'язки даних, команд та змін подій сповіщень. Модель перегляду запитує, спостерігає та координує оновлення моделі, перетворюючи, перевіряючи та агрегуючи дані, необхідні для відображення у поданні."

Я б сказав у вашому ViewModel. Це не є частиною Моделі, оскільки Модель є агностичним інтерфейсом користувача. Модель має бути "ВСЕ ОКРЕМИ ділової агностики"

Реалізація INPC у моделях може бути використана, якщо моделі відкриті в ViewModel. Але загалом, ViewModel обгортання моделей - це його власні класи для зменшення складності моделі (що не повинно бути корисним для прив’язки). У цьому випадку INPC має бути реалізований у ViewModel.

Я використовую INotifyPropertyChangeінтерфейс у моделі. Насправді зміна властивості моделі має бути запущено лише інтерфейсом користувача або зовнішнім клієнтом.

Я помітив кілька переваг і недоліків:

Переваги

Повідомлення є у бізнес-моделі

1. Відповідно до домену, це правильно. Він повинен вирішити, коли піднімати, а коли не робити.

Недоліки

Модель має властивості (кількість, швидкість, комісія, тотальність). Загальна витрата обчислюється за допомогою кількості, кількості, зміни комісії.

1. При завантаженні значень з db, обчислення загального фрейту називається 3 рази (qty, rate, комісія). Це має бути один раз.

2. Якщо швидкість, qty призначена в бізнес-шарі, знову викликається сповіщувач.

3. Повинна бути можливість відключити це, можливо, в базовому класі. Однак розробники могли забути це зробити.

Я думаю, що все залежить від випадку використання.

Якщо у вас є проста модель з навантаженням властивостей, ви можете мати її, реалізуючи INPC. Під простим я маю на увазі, що ця модель виглядає скоріше як POCO .

Якщо ваша модель є більш складною і перебуває в області інтерактивної моделі - моделі, що посилаються на моделі, передплачуючи події інших моделей - проведення модельних подій реалізовано як INPC - це кошмар.

Поставте себе в становищі якоїсь модельної структури, яка має співпрацювати з деякими іншими моделями. У вас є різні події, на які можна підписатися. Усі вони реалізовані як INPC. Уявіть тих обробників подій, які у вас є. Один величезний каскад клавіш if-та / або перемикання.

Ще одна проблема з 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у своїй моделі перегляду, а не в моделі,

зазвичай модель використовує IDataErrorInfoдля обробки помилок перевірки, тому просто тримайтеся у своєму ViewModel і ви прямо на дорозі MVVM.

Припустимо, що посилання на об'єкт у вашому перегляді змінюється. Як ви сповістите про всі оновлені властивості, щоб показати правильні значення? Зателефонувати OnPropertyChangedу ваш погляд на всі властивості об'єкта, на мій погляд, сміття.

Так що я роблю, щоб сам об'єкт повідомити кого - або , коли значення у власності змінюється, і на мій погляд , я використовую прив'язок , як Object.Property1, Object.Property2і. Таким чином, якщо я просто хочу змінити об'єкт, який зараз підтримується, на мій погляд, я просто це роблю OnPropertyChanged("Object").

Щоб уникнути сотень повідомлень під час завантаження об'єктів, у мене є приватний булевий індикатор, що я встановлюю його як істинне під час завантаження, яке перевіряється з об'єкта OnPropertyChangedі нічого не робить.

Зазвичай ViewModel реалізує INotifyPropertyChanged. Модель може бути будь-якою (файл XML, база даних або навіть об’єкт). Модель використовується для передачі даних в модель перегляду, яка поширюється на представлення.

дивіться тут

Я думаю, реалізує INotifyPropertyChangeмодель перегляду, і модель може використовувати сповіщення на іншому "рівні".

наприклад, з деякою службою документування та об'єктом документа у вас є подія documentChanged, яку переглядає модель, щоб очистити та відновити подання. У моделі перегляду редагування ви маєте зміну властивостей властивостей документа для підтримки представлень. Якщо послуга робить багато з документом щодо збереження (оновлення дати зміни, останнього користувача тощо), ви легко отримуєте перевантаження подій Ipropertychanged, і достатньо лише зміненого документа.

Але якщо використовувати INotifyPropertyChange у своїй моделі, я вважаю, що це найкраща практика передати її у вашій моделі перегляду замість передплати на неї безпосередньо у вашому погляді. У тому випадку, коли події у вашій моделі змінюються, вам потрібно змінити лише модуль перегляду, і вигляд залишається недоторканим.

Усі властивості, прив'язані до мого перегляду, перебувають у моїх ViewModel (s). Таким чином, вони повинні реалізувати інтерфейс INotifyPropertyChanged. Тому Погляд отримує всі зміни.

[Використовуючи інструментарій MVVM Light, я дозволяю їм успадковувати з ViewModelBase.]

Модель дотримується ділової логіки, але не має нічого спільного з поглядом. Таким чином, інтерфейс INotifyPropertyChanged не потребує.