像 DisplayMemberPath 这样的属性成为依赖属性的原因/场景是什么？答案

【问题标题】：What are the reasons/scenarios for properties like DisplayMemberPath to be dependency properties?像 DisplayMemberPath 这样的属性成为依赖属性的原因/场景是什么？
【发布时间】：2011-04-15 14:36:39
【问题描述】：

谁能解释一下为什么说 ItemsControl.DisplayMemberPath 是一个依赖属性，而不仅仅是一个常规的 CLR 属性？

当此类属性用于数据绑定场景、样式或其他依赖属性相关的情况时，是否存在任何现实生活场景。

谢谢。

更新：

这个问题的原因是这样的陈述

使您的属性成为依赖项财产并不总是必要的或适当的，将取决于您的需要。有时，典型的支持您的财产的技术有一个私有字段就足够了。

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

【问题讨论】：

标签： .net wpf silverlight properties dependency-properties

【解决方案1】：

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

我在使用 Sync-fusion 等 3 方控件时经常遇到这个问题；在许多情况下，我们提出了要求对各种控件属性的绑定支持的请求。如本问题所述：

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

将此属性设置为 DP 可能有特殊原因，但总的来说，我没有遇到任何不是 DP 的属性（WPF 控件）；这真的很有用，您可以设计 UI（使用绑定、样式等），而无需检查所有控件的每个属性。

【讨论】：

非 DP 属性示例 - stackoverflow.com/questions/3767867/…
这个问题的原因是诸如“使您的属性成为依赖属性并不总是必要或适当的，并且取决于您的需要。有时，使用私有字段支持您的属性的典型技术是足够的。”在 MSDN 文档中。像这样的事情让我质疑不明显的依赖属性声明。
@Alan - 是的，我完全同意你的看法。它令人困惑，您可以根据什么做出决定？如果您在此处查看应该使用 DP 的场景/案例 -msdn.microsoft.com/en-us/library/…，则很难做出决定。

【解决方案2】：

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

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

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

【讨论】：