INotifyPropertyChanged использование вне привязки данных - PullRequest
5 голосов
/ 08 сентября 2011

Я никогда не использовал INotifyPropertyChanged, и я планирую широко использовать его в новом приложении.

У меня вопрос: «Правильно ли» использовать интерфейс INotifyPropertyChanged для предоставления уведомлений о событиях для вещей, отличных от элементов управления с привязкой к данным?

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

Ответы [ 8 ]

4 голосов
/ 08 сентября 2011

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

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

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

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

2 голосов
/ 08 сентября 2011

Я думаю, что вы можете использовать этот Интерфейс для этих сценариев, но вам нужно серьезно задуматься о том, хотите ли вы, чтобы эта связка между этими двумя классами.Если для вас это имеет смысл - конечно, зачем изобретать велосипед?

1 голос
/ 08 сентября 2011

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

0 голосов
/ 08 сентября 2011

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

0 голосов
/ 08 сентября 2011

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

0 голосов
/ 08 сентября 2011

Я думаю, что INotifyPropertyChanged обычно является правильным механизмом для push-уведомлений об обновлениях значений свойств.

Альтернатива:

Однако это неЕдинственно возможный механизм для достижения этой цели.Например, Windows Forms также поддерживает отдельные …Changed события для свойства;т. е. если у вас есть свойство с именем Foo, вы можете иметь ассоциированное событие FooChanged, которое будет запускаться в установщике Foo.

Наличие отдельных событий …Changed имеет преимущество, заключающееся в специфичностик одному конкретному свойству и, следовательно, не требует от наблюдателей / подписчиков отфильтровывать уведомления о свойствах, которые им не интересны. С другой стороны, ваши объекты (данные) могут начать чувствовать себя «громоздкими», как только вы объявитедополнительные события …Changed.

Некоторые замечания о реализации INotifyPropertyChanged:

  • Если вы устали переписывать тот же самый шаблонный кодснова и снова ...:

    public T SomeProperty
    {
        get { … }
        set
        {
            if (someProperty != value)
            {
                someProperty = value;
                NotifyPropertyChanged("SomeProperty");
            }
        }
    }
    private T someProperty;
    

    тогда вы, возможно, захотите рассмотреть инфраструктуру AOP (например, PostSharp).Я помню, что на CodePlex или в Google Code существует библиотека, которая автоматически реализует INotifyPropertyChanged для вас (или переписывает байт-код CIL);к сожалению, я не могу вспомнить название библиотеки.

  • Есть и другие связанные интерфейсы INotifyPropertyChanging, INotifyListChanged и т. д. Возможно, вы захотите посмотреть и на них.1036 *

0 голосов
/ 08 сентября 2011

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

Для моих собственных типов и сценариев я бы использовал обычные события (одно событие на каждое свойство, которое может изменить его значение).INotifyPropertyChanged в таких сценариях является типом строго типизированного кода.Вы можете видеть, что даже сам WPF все еще полон событий oldscool ( FrameworkElement , например, с большим количеством событий ***Changed).

0 голосов
/ 08 сентября 2011

WPF и Silverlight оба широко используют INotifyPropertyChanged в системе привязки данных.Если вы собираетесь привязывать данные к вашим объектам, вам обязательно следует использовать INotifyPropertyChanged.|

В остальном, насколько я знаю, это не влияет на технологии .NET Framework.

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

...