Реализация INotifyProperty изменена на статическое свойство в WPF и Silverlight

Question

Вопрос в том, как реализовать INotifyPropertyChanged для статического свойства, поскольку реализуемое вами событие не является статическим и не может быть вызвано статическим свойством. Кроме того, вы не можете привязать статическое свойство в Silverlight.

Я видел этот вопрос на нескольких форумах с различными решениями, ни один из которых не был очень удовлетворительным.

Ну, я думаю, что нашел элегантное решение, но оно настолько простое, что мне кажется, что я что-то упустил.

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

    private static double length;
    public double Length
    {
        get
        {
            return length;
        }
        set
        {
            length = value;
            NotifyPropertyChanged("Length");
        }
    }

Я проверил это, и, кажется, работает нормально. Я что-то упустил?

Answer 1

Технически, вы все еще не привязываете к статическому свойству - вы привязываете к экземпляру класса, который использует статическое поле в качестве резервного хранилища. Это будет работать в некоторой степени, но ...

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

Скажем, например, у вас было два элемента UserControl, расположенных рядом друг с другом, оба связаны с ViewModel, содержащей этот код. Когда элемент управления A устанавливает это свойство, элемент управления B никогда не будет получать уведомления (поскольку выполняется INotifyPropertyChanged A), поэтому он будет отображаться не синхронизировано.

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

В качестве альтернативы вы можете рассмотреть возможность использования единственного свойства экземпляра (с полем экземпляра) внутри Singleton . Это также даст вам общие уведомления о вашем "статическом" свойстве.

Answer 2

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

Извините, но я думаю, что вы делаете это неправильно.
Лично, не зная, какой у вас сценарий, я могу предположить, что привязка статического свойства на самом деле не является техническим решением, которое вам нужно.
В чем проблема, которую вы пытаетесь решить?
Почему это лучше не решается обычной привязкой к ViewModel?
Какой смысл делать что-то подобное?

Лично это выглядит как идеальный сценарий, когда ViewModel регистрируется в одноэлементном сервисе, и как только одноэлементное событие возникает, меняйте свойства ViewModel.

Answer 3

Почему свойство должно быть статичным? Если бы это было просто свойство обычного экземпляра, это не было бы проблемой.

Избегайте общего изменяемого состояния, когда это возможно:)

Answer 4

замки для многопоточности?

C # потокобезопасность с get / set