При использовании шаблона MVVM должен ли код, относящийся к изменениям свойств, идти в установщик или событие? - PullRequest
Новая
       13

При использовании шаблона MVVM должен ли код, относящийся к изменениям свойств, идти в установщик или событие?

4 голосов
/ 16 сентября 2010

Требуется руководство по размещению кода, который зависит от изменений свойства.

Например, у меня есть модель представления, которая используется для хранения состояния для настроек приложения 

public SettingsViewModel(ISettingsRepository settings)
{
    _settings = settings;
    // ...
}

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

Я начал с добавления этой логики вустановщик 

public ProjectCollection Projects
{
    get { return _projects; }
    set
    {
        if (_projects == value) return;
        _projects = value;
        RaisePropertyChanged("Projects");

        // Extra work needed when collection of projects change
        _settings.SaveProjects(_projects);
        Startable = _projects != null && _projects.Count > 0;
    }
}

Но затем переключился на связывание события PropertyChanged для INotifyPropertyChanged и удалил дополнительный код из установщика свойств 

public SettingsViewModel(ISettingsRepository settings)
{
    _settings = settings;
    // ...
    PropertyChanged += onPropertyChanged;
}

void onPropertyChanged(object sender, PropertyChangedEventArgs e)
{
    switch (e.PropertyName)
    {
        case "Projects":
            _settings.SaveProjects(Projects);
            Startable = Projects != null && Projects.Count > 0;
            break;
        // ...
    }
}

public ProjectCollection Projects
{
    get { return _projects; }
    set
    {
        if (_projects == value) return;
        _projects = value;
        RaisePropertyChanged("Projects");
    }
}

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

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

Я понимаю, что это субъективный вопрос, но я новичок в паттерне MVVM (хотя я полагаю, что это может быть справедливо для любой логики сеттера?), Поэтому я ищу другие причины, прежде чем остановиться на подходе.Спасибо!

1 Ответ

4 голосов
/ 16 сентября 2010

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

Установщики свойств должны быть максимально простыми, и они должны уведомлять, если что-то полагается на них (чтов основном так и будет - виртуальная машина используется для привязки).Это означает, что ваш второй пример, использующий обработчик событий OnPropertyChanged(), гораздо лучше, чем первый.

Тем не менее, он все еще знает слишком много для моей симпатии .Я хотел бы сообщить о событиях, на которые может подписаться Модель, и пусть Модель сделает всю работу.ViewModel должен просто сказать «эй, мои данные изменились, мне все равно, что вы с этим делаете, но я сказал вам, что делайте что хотите» * .Затем модель может либо мгновенно сохранить данные, либо еще какие-либо изменения, прежде чем сохранить данные.

...