Обычно повышение свойства изменения PropertyChangeNotification в другом классе

У меня есть два класса:

  1. ViewModelA
  2. MainViewModel.

Оба реализуют интерфейс INotifyPropertyChanged.

MainViewModel содержит наблюдаемую коллекцию объектов ViewModelA. Мне нужно изменить определенное свойство «X» в любом классе ViewModelA, чтобы вызвать уведомление о изменении свойства в свойстве «Y» в MainViewModel.

Вопрос 1. Как обычно это реализуется?

Вопрос 2: прослушивает CollectionChanged в ObservableCollection и прикрепляет/удаляет обработчик событий (который проверял бы, было ли изменено свойство «X», и если да, вызывало бы уведомление об изменении свойства «Y») a плохая практика? Если да, то почему?


viewmodel mvvm c# inotifypropertychanged propertychanged
person kajovajo    schedule 28.08.2013    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Я бы реализовал свое собственное событие в ViewModelA и подписался на него при создании новой ViewModelA в MainViewModel. Событие будет вызвано в ViewModelA, если что-то случится.

person BendEg    schedule 28.08.2013

arrow_upward
0
arrow_downward

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

В вашем конкретном случае вы хотите вызвать событие INotifyPropertyChanged с некоторым свойством в модели основного представления для обновления пользовательского интерфейса.

По сути, вы смотрите на некий производный от Шаблон проектирования Observer, благодаря которому вы каким-то образом "слушаете" изменения в дочерней модели представления, и родитель уведомляется. Две реализации этого шаблона легко доступны для использования:

  1. События. Как уже ответил кто-то другой на этот вопрос, вы можете создать событие в дочерней модели представления и подписаться на это событие напрямую от родителя. Лично я избегаю определения событий в моих моделях представления, где это возможно — для меня модель представления является логическим представлением представления, и наличие открытого события в интерфейсе модели представления, кажется, идет вразрез с зерном.

  2. Агрегатор событий. Использование агрегатора событий ( например тот, который предоставляется PRISM) позволяет вам подписаться на сообщения в родительской модели представления, которые запускаются из дочерней модели представления. Цена, которую вы платите за то, что вам не нужно определять публичное событие в дочерней модели представления, зависит от реализации IEventAggregator. Мне нравится этот подход, поскольку он разделяет проблемы родительской и дочерней моделей представления и взаимодействие между ними. Одно предупреждение: использование агрегатора событий открыто для злоупотреблений, и если вы используете его небрежно, это может затруднить отслеживание всех сообщений, которые летают вокруг вашего приложения.

person Lawrence    schedule 28.08.2013