Каковы причины / сценарии для свойств, таких как DisplayMemberPath, чтобы быть свойствами зависимости?

Question

Может ли кто-нибудь объяснить причину, по которой, скажем, ItemsControl.DisplayMemberPath является свойством зависимости, а не просто обычным свойством CLR?

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

Спасибо.

Обновление:

Причиной для этого вопроса являются утверждения типа

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

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

Answer 1

Согласованность : Как разработчик, вы не можете предполагать, что никому там не понадобится определенная функция (в конкретном случае).Когда я разрабатываю какой-либо пользовательский элемент управления, я делаю все открытые свойства DP, так как вы никогда не знаете, что кто-то, использующий этот элемент управления / свойство, может иметь требование связать его или использовать его в стиле и т. Д. Так что лучше быть последовательным;так как если некоторые свойства элементов управления поддерживают связывание, стилизацию и т. д., я ожидаю, что другие свойства также будут их поддерживать.

Я часто сталкивался с этой проблемой при использовании сторонних элементов управления, таких как Sync-fusion;Много раз мы собирали билеты с просьбой о поддержке Binding для различных управляющих свойств.Как уже упоминалось в этом вопросе:

Почему так много элементов управления wpf реализуют свойства CLR вместо свойств зависимостей?

Может быть особая причина для использования этого свойства как DPно в целом я не сталкивался ни с каким свойством (WPF Controls), которое не является DP;и это действительно полезно, вы можете создавать пользовательский интерфейс (используя привязку, стилизацию и т. д.), не проверяя каждое свойство всех элементов управления.

Answer 2

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

Например, если вы хотите создать DataGrid, где вы динамически управляетестолбцы, вам может понадобиться привязать DisplayMemberPath к какому-либо свойству вашей ViewModel.

Вы также можете установить его в триггере стиля или шаблона, чтобы отображать тот или иной элемент в зависимости от некоторых условий.