我正在构建一个Silverlight应用程序，上次的警告是，如果我们需要以Silverlight / WPF方式正确完成任何事情，则需要将对象建模为DependecyObject并使用DependencyProperty

我发现此模型相当麻烦，需要在我使用的类的一半中使用静态字段和初始化程序，因此，使用老式的事件驱动(观察者模式)代替DependencyObject是一个好主意吗？

我的目标是最大程度地减少代码膨胀和重复步骤(我讨厌它们)，并且真的想知道是否有在Silverlight / WPF中具有丰富经验的人有任何技巧/技术来将DependencyObject和DependencyProperty的使用率降至最低？

这是一个好主意吗？

解决方案

这实际上取决于我们所指的对象。如果对象打算放在XAML树中，则最好使用DependencyProperties(并继承所有UIElement所做的DependencyObject)以允许DependencyProperties提供的所有好处(可动画，绑定，可选的自动子继承等)。我强烈建议我们阅读DependencyProperties上的MSDN概述(如果我们还没有的话)。

如果对象是数据实体(即，我们将其值绑定到XAML树中的某个对象)，则无需从DependencyObject继承。如果对象上的属性是可读写的，则可能需要实现INotifyPropertyChanged，该方法将使绑定在值更改时自动更新。

实际上，在Silverlight中，我们不能继承DependencyObjects，因此我们应该(必须)实现INotifyPropertyChanged。

与DependencyObjects相比，实现INotifyPropertyChanged具有许多优势(为了简化起见，我将简化此DO)并使用DependencyProperties(DP)：

• 这更轻巧
• 赋予我们更多建模对象的自由
• 可以轻松序列化
• 我们可以在需要时引发事件，这在某些情况下很有用，例如，当我们只想在一个UI操作中捆绑多个更改时，或者即使数据没有更改(强制重画...)

另一方面，在WPF中继承DO具有以下优点：

• 特别是对于初学者来说，更容易实现。
• 我们将获得(几乎)免费的回调机制，使我们可以在属性值更改时收到通知
• 我们将获得强制机制，可使用该机制定义属性的最大值，最小值和当前值的规则。

还有其他考虑因素，但这是主要的考虑因素。

我认为普遍的共识是，DP非常适合控件(我们甚至可以在Silverlight中使用自定义DP来实现CustomControl)，但是对于数据对象，我们应该实现INotifyPropertyChanged。

HTH，
劳伦特

我同意Richard的观点，这取决于类的用途，但需要注意的是，我们似乎可以直接在Silverlight 2.0版本中从DependencyObject继承，而不必从UIElement或者UserControl继承。至少，我是在(SilverLight 2.0 RTW)应用程序中执行此操作的。

MSDN上的System.Windows.DependencyObject

It is not typical to derive directly from DependencyObject for most scenarios. Instead you might derive from a specific control, from one of the control base classes (ContentControl; Control; ItemsControl), from FrameworkElement, or from non-control classes that still participate in UI such as Panel or Grid. Deriving from DependencyObject might be appropriate if you are defining a business or data storage object where you want dependency properties to be active, or if you are creating a service support class that will own attached properties.

高温超导