Внедрение INotifyProperty изменено на статическое свойство в WPF и Silverlight

Question

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

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

Ну, я думаю, что нашел изящное решение, но это так просто, я чувствую, что мне что-то не хватает.

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

C# thread safety with get/set

Answer 3

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

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

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

Answer 4

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

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