В MVVM должен ViewModel или Model реализовать INotifyPropertyChanged?

Question

Большинство примеров MVVM, с которыми я работал, имели Model , реализующую INotifyPropertyChanged, но в Пример CommandSink Джоша Смита ViewModel реализует INotifyPropertyChanged .

Я все еще когнитивно собираю концепции MVVM, поэтому не знаю, если:

• Вы должны поместить INotifyPropertyChanged в ViewModel, чтобы заставить CommandSink работать
• это просто отклонение от нормы, и это на самом деле не имеет значения
• у вас всегда должна быть модель, реализующая INotifyPropertyChanged, и это просто ошибка, которая будет исправлена, если она будет разработана из примера кода для приложения

Каким был опыт других в проектах MVVM, над которыми вы работали?

Answer 1

Просто используйте INotifyPropertyChange в вашей модели просмотра, а не в модели,

модель обычно использует IDataErrorInfo для обработки ошибок валидации, так что просто держитесь в своей ViewModel, и вы находитесь прямо на пути MVVM.

Answer 2

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

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

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

Answer 3

Я использую интерфейс INotifyPropertyChange в модели. На самом деле изменение свойства модели должно выполняться только пользовательским интерфейсом или внешним клиентом.

Я заметил несколько преимуществ и недостатков:

Преимущества

Уведомитель в бизнес-модели

1. Что касается домена, это правильно. Он должен решить, когда повышать, а когда нет.

Недостатки

Модель имеет свойства (кол-во, ставка, комиссия, общая сумма). Totalfrieght рассчитывается с использованием кол-во, ставка, изменение комиссии.

1. При загрузке значений из дБ, расчет общего веса вызывается 3 раза (кол-во, ставка, комиссия). Это должно быть один раз.

2. Если на бизнес-уровне назначена скорость, кол-во, снова вызывается уведомитель.

3. Должна быть возможность отключить это, возможно, в базовом классе. Однако разработчики могли забыть сделать это.

Answer 4

Обычно ViewModel реализует INotifyPropertyChanged. Модель может быть чем угодно (XML-файл, база данных или даже объект). Модель используется для передачи данных в модель представления, которая распространяется в представление.

см. Здесь

Answer 5

Все свойства, которые связаны с моим представлением, находятся в моих ViewModel (s). Таким образом, они должны реализовать интерфейс INotifyPropertyChanged. Поэтому View получает все изменения.

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

Модель содержит бизнес-логику, но не имеет ничего общего с представлением. Таким образом, нет необходимости в интерфейсе INotifyPropertyChanged.

Answer 6

Реализация INPC в моделях может быть использована, если модели открыто отображаются во ViewModel. Но, как правило, ViewModel обертывание моделей - это его собственные классы, чтобы уменьшить сложность модели (которая не должна быть полезной для привязки). В этом случае INPC должен быть реализован во ViewModel.

Answer 7

Предположим, что ссылка на объект в вашем представлении изменяется. Как вы будете уведомлять все свойства, которые будут обновлены, чтобы показать правильные значения? На мой взгляд, вызов OnPropertyChanged для всех свойств объекта - это чушь.

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

Чтобы избежать сотен уведомлений во время загрузки объектов, у меня есть частный логический индикатор, который я установил в значение true во время загрузки, который проверяется из OnPropertyChanged объекта и ничего не делает.