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

Большинство примеров MVVM, с которыми я работал, имели реализацию ModelINotifyPropertyChanged , но в примере CommandSink Джоша Смита реализована ViewModelINotifyPropertyChanged .

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

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

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

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

Я уверен, что другие не согласятся, но так я работаю.

Я категорически не согласен с концепцией, что Модель не должна реализовывать INotifyPropertyChanged. Этот интерфейс не зависит от пользовательского интерфейса! Это просто сообщает об изменении. Действительно, WPF активно использует это для выявления изменений, но это не значит, что это интерфейс пользовательского интерфейса. Я бы сравнил это со следующим комментарием: « Шина - это автомобильный аксессуар ». Конечно, но велосипеды, автобусы и т. Д. Тоже им пользуются. Итак, не воспринимайте этот интерфейс как интерфейс.

Сказав это, это не обязательно означает, что я считаю, что Модель должна предоставлять уведомления. На самом деле, как правило, модель не должна реализовывать этот интерфейс, если в этом нет необходимости.В большинстве случаев, когда данные сервера не передаются клиентскому приложению, модель может устареть. Но если слушать данные финансового рынка, то я не понимаю, почему модель не может реализовать интерфейс. Например, что если у меня есть логика, не связанная с пользовательским интерфейсом, например, служба, которая, когда она получает цену Bid или Ask для данного значения, выдает предупреждение (например, по электронной почте) или размещает заказ? Это может быть возможным чистым решением.

Тем не менее, существуют разные способы достижения цели, но я бы всегда выступал за простоту и избегал избыточности.

Что лучше? Определить события в коллекции или изменения свойств в модели представления и распространить их на модель или иметь представление, чтобы обновить модель (через модель представления)?

Суть в том, что когда вы видите кого-то, заявляющего, что « вы не можете делать то или это », это признак того, что он не знает, о чем говорит.

Это действительно зависит от вашего случая, и на самом деле 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, который контролирует данные, независимо от того, кто пытается их коснуться.

Если вы рассматриваете модель представления как нечто большее, чем DataController, и реализуете архитектуру, в которой ваш DataController является единственным элементом, который касается данных, то вы никогда не будете касаться данных напрямую, но всегда будете использовать DataController. DataController полезен для пользовательского интерфейса, но не обязательно только для пользовательского интерфейса. Это для бизнес-уровня, пользовательского интерфейса и т. Д.

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

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

Это зависит от того, как вы реализовали свою модель. Моя компания использует бизнес-объекты, подобные объектам Lhotka CSLA, и широко использует INotifyPropertyChangedвсю бизнес-модель.

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

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

Я согласен с ответом Пауло, что внедрение INotifyPropertyChangedв моделях вполне приемлемо и даже предлагается Microsoft -

Как правило, модель реализует средства, облегчающие привязку к представлению. Как правило , это означает , что он поддерживает свойство и сбор изменено уведомление через INotifyPropertyChangedи INotifyCollectionChangedинтерфейсы. Классы моделей, представляющие коллекции объектов, обычно являются производными от ObservableCollection<T>класса, который обеспечивает реализацию INotifyCollectionChangedинтерфейса.

Хотя вам решать, хотите ли вы этот тип реализации или нет, но помните -

Что если в ваших модельных классах не реализованы необходимые интерфейсы?

Иногда вам нужно будет работать с модельными объектами , которые не реализуют INotifyPropertyChanged, INotifyCollectionChanged, IDataErrorInfoили INotifyDataErrorInfoинтерфейсы. В этих случаях модели представления может потребоваться обернуть объекты модели и предоставить необходимые свойства представлению. Значения этих свойств будут предоставлены непосредственно объектами модели. Модель представления будет реализовывать необходимые интерфейсы для свойств, которые она предоставляет, чтобы представление могло легко привязать к ним данные.

Взято с - http://msdn.microsoft.com/en-us/library/gg405484(PandP.40).aspx

Я работал в некоторых проектах, где мы не реализовали INotifyPropertyChangedнаши модели, и из-за этого мы столкнулись с множеством проблем; ненужное дублирование свойств было необходимо в ВМ, и в то же время нам пришлось обновить базовый объект (с обновленными значениями), прежде чем передавать их в BL / DL.

Вы столкнетесь с проблемами, особенно если вам нужно работать с коллекцией объектов вашей модели (скажем, в редактируемой сетке или списке) или со сложными моделями; объекты модели не будут обновляться автоматически, и вам придется управлять всем этим в вашей виртуальной машине.

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

Я думаю, что ответ вполне ясен, если вы хотите придерживаться MV-VM.

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

В шаблоне MVVM представление инкапсулирует UI и любую логику UI, модель представления инкапсулирует логику и состояние представления, а модель - бизнес-логику и данные.

«Представление взаимодействует с моделью представления посредством привязки данных, команд и событий уведомлений об изменениях. Модель представления запрашивает, наблюдает и координирует обновления модели, преобразовывая, проверяя и агрегируя данные, необходимые для отображения в представлении».

Я бы сказал в вашей ViewModel. Это не часть Модели, поскольку Модель не зависит от пользовательского интерфейса. Модель должна быть «все, кроме бизнес-агностика»

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

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

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

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

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

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

Недостатки

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

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

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

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

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

Если у вас есть простая модель с множеством свойств, вы можете использовать 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 может измениться».

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

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

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

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

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

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

посмотреть здесь

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

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

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

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

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

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