Если каждое поле, поддерживающее реквизиты виртуальной машины, реализует INotifyPropChange, должна ли виртуальная машина реализовать INotifyPropChagned?

Question

Если моя модель реализует INotifyPropertyChanged и нужна ли моя виртуальная машина?

Пояснение: В реальном случае, когда у вас есть SomeOtherProp, тогда INotifyPropertyChanged абсолютно необходимо реализовать.Что мне действительно нужно, так это то, сколько работы мне нужно выполнить (реплицировать) для правильно сформированных моделей.

Пример:

namespace Question
{
    public interface IFoo : INotifyPropertyChanged { }
    public interface IBar : INotifyPropertyChanged { }

    public interface IModel : INotifyPropertyChanged
    {
        IFoo Foo { get; set; }
        ObservableCollection<IBar> BarCollection { get; }
    }

    public class VM : TypeSafeViewModelBase
    //Clarification: added VM base clase with typesafe override for RaisePropertyChanged
    {
        private IModel _model;
        public VM( IModel model )
        {
            this._model = model;
            //Clarification: added this call...
            this._model.PropertyChanged += ( sender, args ) => base.RaisePropertyChanged(args.PropertyName);
            //That is the one I have questions about and ultimateley what I  want to avoid
        }

        public IFoo Foo { get { return this._model.Foo; } }
        public ObservableCollection<IBar> BarCollection { get { return this._model.BarCollection; } }

        //clarification: added this prop declaration
        //I know this would be needed as this property is backed by a private member of this class
        private string _someOtherProp;
        public string SomeOtherProp
        {
            get { return this._someOtherProp; }
            set
            {
                this._someOtherProp = value;
                base.RaisePropertyChanged(() => this.SomeOtherProp);
            }
        }
    }
}

Нужно ли ВМ внедрять INotifyPropertyChanged?И передать все события в V?Или вещи в V связываются с объектами самого низкого уровня, которые реализуют интерфейсы PropertyChanged и CollectionChanged?

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

PS.Я разрабатываю в SL4, используя Prism и Ninject, если это имеет значение.Моя модель изменчива, с сохранением состояния и в локальной памяти (я держу локальный кеш, потому что попадание на сервер после каждой операции нецелесообразно).

Answer 1

Нет, вам не нужно реализовывать сам интерфейс в вашем случае.Например, виртуальной машине не нужно реализовывать INotifyPropertyChange, если вы используете бизнес-объект служб RIA, поскольку те уже реализуют его.

Однако!Скорее всего, вы все еще хотите это сделать, потому что такие свойства, как «IsBusy», «CanSave» и т. Д. Обычно принадлежат самой ВМ, и тогда вам нужен интерфейс.реализует INotifyPropertyChanged, INotifyDataErrorInfo и так далее.И каждая ВМ наследуется от этого базового класса

Answer 2

Существует штраф за реализацию и поддержку любой абстракции, а в случае MVVM есть немало склеенного кода, который неизбежен.Вопрос не в том, подходит ли клейкий код, а в том, подходит ли сама абстракция?У вас есть повторное использование в ваших viewmodels?Вы интенсивно используете привязку данных?Является ли модульное тестирование ваших моделей представления чем-то, что делает ваша команда?или интеграционное тестирование ваших моделей представления является частью вашего цикла разработки?

Чтобы конкретно ответить на ваш вопрос, в вашем проекте модель выполняет некоторую работу для модели представления, реализуя INotifyPropertyChanged и предоставляя наблюдаемые коллекции.Мне нравится реализовывать свои модели, используя как можно больше базового языка и библиотек.Это означает, что мои коллекции будут общими списками, хэш-наборами и т. Д., И мой механизм обработки событий будет включать в себя настраиваемые события и делегаты (реализованные в виде агрегатора событий).

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