INotifyPropertyChanged против DependencyProperty в ViewModel

Кент написал интересный блог на эту тему: Модели просмотра: POCOs против DependencyObjects .

Я предпочитаю подход POCO. Базовый класс для PresentationModel (он же ViewModel), который реализует интерфейс INotifyPropertyChanged, можно найти здесь: http://compositeextensions.codeplex.com

Согласно руководству по производительности WPF, DependencyObjects определенно работает лучше, чем POCO, которые реализуют INotifyPropertyChanged:

http://msdn.microsoft.com/en-us/library/bb613546.aspx

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

DependencyProperties будет применяться в основном на уровне VisualElements, поэтому было бы не лучшим решением создавать множество DP для каждого из наших бизнес-требований. Кроме того, DP дороже, чем INotifyPropertyChanged. Когда вы разрабатываете WPF / Silverlight, постарайтесь полностью разделить UI и ViewModel, чтобы в любой момент мы могли изменить элементы управления Layout и UI (на основе темы и стилей).

См. Также этот пост - https://stackoverflow.com/questions/275098/what-applications-could-i-study-to-understand-datamodel-view-viewmodel. Ссылка содержит много ссылок на шаблон Model-View-ViewModel, который очень важен для этого обсуждения.

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

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

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

"Чтобы быть источником привязки, свойство не обязательно должно быть свойством зависимости; вы можете использовать любое свойство CLR в качестве источника привязки. Однако, чтобы быть целью привязки, свойство должно быть Свойство зависимости. Чтобы односторонняя или двусторонняя привязка была эффективной, свойство источника должно поддерживать уведомления об изменениях, которые распространяются на систему привязки и, следовательно, на цель. Для настраиваемых источников привязки CLR это означает, что свойство должно поддерживать INotifyPropertyChanged. Коллекции должны поддерживать INotifyCollectionChanged. "

Все объекты зависимостей не могут быть сериализованы (это может помешать использованию ViewModels и DTO (POCO).

Между DP в Silverlight и WPF есть отличия.

http://msdn.microsoft.com/en-us/library/cc221408(v=VS.95).aspx.

http://msdn.microsoft.com/en-us/library/cc903933(VS.95).aspx

INotifyPropertyChanged при использовании также дает вам возможность добавить больше логики в код ваших методов получения и установки ваших свойств.

DependencyProperty пример:

public static DependencyProperty NameProperty = DependencyProperty.Register( "Name", typeof( String), typeof( Customer ) );

public String Name
{
    set { SetValue( NameProperty, value ); }
    get { return ( String ) GetValue( NameProperty ); }
}

В вашем геттере и сеттере - все, что вы можете сделать, это просто вызвать SetValue и GetValue соответственно, b / c в других частях фреймворка геттер / сеттер не вызывается, вместо этого он напрямую вызывает SetValue, GetValue, поэтому ваша логика свойств не будет надежно исполниться.

С помощью INotifyPropertyChanged определите событие:

public event PropertyChangedEventHandler PropertyChanged;

А затем просто имейте любую логику в любом месте вашего кода, затем вызовите:

// ...
// Something cool...
// ...

if( this.PropertyChanged != null )
{
    PropertyChanged( this, new PropertyChangedEventArgs( "Name" ) );
}

// More cool stuff that will reliably happen...

Это может быть геттер / сеттер или где-нибудь еще.

Это действительно хорошая идея передать зависимости ViewModel в WPF?

.NET 4.0 будет иметь System.Xaml.dll, поэтому вам не придется зависеть от произвольной структуры, чтобы использовать его. См. сообщение Роба Рельеа о его сеансе PDC.

Мое мнение

XAML - это язык для описания объектов, а WPF - это платформа, описанные объекты которой являются элементами пользовательского интерфейса.

Их отношения аналогичны C #, языку описания логики, и .NET, структуре, реализующей определенные виды логики.

Назначение XAML - декларативные графы объектов. Технологии W * F - отличные кандидаты для этой парадигмы, но XAML существует независимо от них.

XAML и вся система зависимостей были реализованы как отдельные стеки для WF и WPF, вероятно, чтобы использовать опыт разных команд без создания зависимости (без каламбура) между ними.

Мне тоже недавно пришлось обдумывать это решение.

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

С DP вы не можете определить серверную часть, которая хранит состояние самостоятельно. Мне пришлось бы разрешить .net кэшировать копию каждого элемента состояния, к которому я привязан. Это выглядело как ненужные накладные расходы - мое состояние большое и сложное.

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

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

Итак, я обнаружил, что DP полезен для уведомлений от графического интерфейса пользователя к графическому интерфейсу.

Свойства зависимостей являются основой создания настраиваемого элемента управления. Если вы заинтересованы в использовании Intelli-sense для отображения ваших свойств в окне свойств во время разработки XAML, вы должны использовать свойства Dependency. INPC никогда не будет отображать свойство в окне свойств во время разработки.

Кажется, что свойства зависимостей следует использовать в элементах управления, которые вы создаете, например в кнопках. Чтобы использовать свойства в XAML и использовать все функции WPF, эти свойства должны быть Dependency Properties.

Однако для вашей ViewModel лучше использовать INotifyPropertyChanged. Использование INotifyPropertyChanged даст вам возможность иметь логику получения / установки, если вам нужно.

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

http://joshsmithonwpf.wordpress.com/2007/08/29/a-base-class-which-implements-inotifypropertychanged/

Я думаю, что это отличный пример того, как создать ViewModel.

Я думаю, что DependencyProperty и INotifyPropertyChanged используются в Binding для двух разных целей: первая для включения свойства в качестве цели привязки и получения входных данных от другого свойства (используйте {Binding ...} для установки свойства), а последняя когда вы хотите, чтобы значение свойства использовалось в качестве источника привязки (имя в выражении пути привязки). Так что выбор чисто технический.

Я предпочитаю более прямой подход, о котором я писал в блоге Модель представления без INotifyPropertyChanged. Используя альтернативу привязке данных, вы можете выполнять привязку непосредственно к свойствам среды CLR без какого-либо бухгалтерского кода. Вы просто пишете простой старый код .NET в своей модели представления, и он обновляется при изменении модели данных.

Есть только одна вещь, почему предпочесть DependencyObject - привязка будет работать лучше. Просто попробуйте пример с ListBox и TextBox, заполните список данными из свойства INotifyPropertyChanged по сравнению с DependencyProperty и отредактируйте текущий элемент из _6 _...

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