DisplayMemberPath等属性成为依赖属性的原因/场景是什么？

Question

有人能解释为什么说ItemsControl.DisplayMemberPath是一个依赖属性而不仅仅是一个普通的CLR属性？

在数据绑定方案，样式或其他依赖属性相关的情况下使用此类属性时是否存在任何实际场景。

感谢。

更新

这个问题的原因是像

这样的陈述

  

使您的财产成为依赖   财产并非总是必要或   适当的，取决于你的   需要。有时，典型的   支持你的财产的技术   私人领域就足够了。

在MSDN documentation中哪种控件开发人员质疑依赖属性的声明，这些声明没有明确可识别的依赖属性的好处。私有字段就足够了。

Answer 1

一致性：作为开发人员，您不能假设那里没有人需要特定功能（在特定情况下）。当我开发任何自定义控件时，我确保创建所有公共属性DP，因为你从来不知道使用该控件/属性的人可能需要绑定它或在样式中使用它。所以最好保持一致;因为，如果某些控件属性支持Binding，样式等，我希望其他属性也支持它们。

我已经面对这个问题了很多第三方控制，如同步融合;我们曾多次提出过要求对各种控制属性进行绑定支持的门票。如本问题所述：

Why do so many wpf controls implement CLR properties instead of dependency properties?

将此属性作为DP可能有一个特殊原因，但一般来说，我没有遇到任何不属于DP的属性（WPF控件）;这非常有用，您可以设计UI（使用Binding，样式等），而无需检查所有控件的每个属性。

Answer 2

DisplayMemberPath可能很少用绑定定义，但我可以想到它会有用的场景......

例如，如果要创建动态控制列的DataGrid，则可能需要将DisplayMemberPath绑定到ViewModel的某个属性。

您还可以在样式或模板触发器中设置它，以根据某些条件显示一个或另一个成员。