Полезна ли конструкция Self в Silverlight / MVVM? - PullRequest
4 голосов
/ 02 августа 2011

Я унаследовал проект Silverlight с сомнительным качеством кода в целом, и есть одна конструкция, в которой я не уверен, стоит ли мне его трогать:

public SomeClass Self
{
    get
    {
        return this;
    }
}

Используется в привязках XAML с параметрами, иногда такими сложными:

Visibility="{Binding Self, ConverterParameter=!, Converter={StaticResource SmartAssConverter}}"

И он используется в уведомлении PropertyChanged (MVVM Light):

RaisePropertyChanged("Self");

Итак, что-то мешает мне просто сделать это:

Visibility="{Binding ConverterParameter=!, Converter={StaticResource SmartAssConverter}}"

который, как я тестировал, все еще показывает нормально?

Перефразируя мой вопрос, является ли необходимость «поднять свойство изменено», заставляя этот вид (ИМХО некрасивой) конструкции?

Редактировать: еще раз перефразируя, есть ли более элегантное решение для уведомления связанных элементов управления об изменении их цели, или я должен изучить переработку конвертеров?

Ответы [ 3 ]

2 голосов
/ 02 августа 2011

Что если объект (то есть Self) изменится?При использовании свойства Self вы можете использовать интерфейс INotifyPropertyChanged, чтобы указать привязку к обновлению.Если вы удалите свойство, то как бы вы обновили?

Вы можете попробовать сделать RaisePropertyChanged(string.Empty), но я не думаю, что это сработает.

Как правило, преобразователи будут просто переданысвойства, которые им нужны, а не весь объект.Но в Silverlight нет MultiBinding, поэтому вы ограничены одним свойством.

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

1 голос
/ 02 августа 2011

Код, который вы показали, выглядит немного неуклюже, но я не думаю, что он настолько плох, что его нужно переработать. Вы правы, вы можете полностью удалить путь, и это сработает для одноразовой оценки привязки. Однако вызывает беспокойство то, что код вызывает изменение свойства для «Self», чтобы переоценить привязки (отличный хак ... Я запомню это для будущего использования!)

Правильный подход здесь заключается в том, чтобы изменить сам DataContext, это, по сути, изменение 'self' и приведет к переоценке всей привязки.

Лично я бы не стал тратить на это слишком много времени, я видел намного худшее!

1 голос
/ 02 августа 2011

Обычно я реализую интерфейсы IChangeTracking и INotifyPropertyChanged , а затем выполняю следующие действия в конструкторе по умолчанию:

public SomeClass()
{
    this.PropertyChanged += new PropertyChangedEventHandler(OnNotifiedOfPropertyChanged);
}

private void OnNotifiedOfPropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (e != null && !String.Equals(e.PropertyName, "IsChanged", StringComparison.Ordinal))
    {
        this.IsChanged = true;
    }
}

IsChanged propertyrasies уведомление об изменении свойства, и поэтому вы можете связываться с IsChanged, чтобы получать уведомления, когда класс был изменен, без необходимости выставлять сам класс как свойство «Self».

...