Silverlight/WPF中DependencyProperty使用陷阱一枚

短命女 2021-11-11 02:50 333阅读 0赞

今天有朋友写Silverlight代码遇到一个问题，让我一起看一下。这是他写的一个测试类：

使用代码如下：

[![76e073b4-59e4-4e46-b97e-3445c93aea76][]][76e073b4-59e4-4e46-b97e-3445c93aea76 1]

可见，当foo2刚刚创建时，Bars中已经有一个元素了。

SL/WPF达人们看到这里肯定已经笑了，我刚开始学习DependencyProperty时也曾在这个问题上卡住。

在Immediate Window中测试foo1与foo2的Bars属性：

[![image][]][image 1]

果然，Bars其实是同一个List<int>对象。

朋友说，我上网查了，已经知道像List这些集合类属性不能用DependencyProperty Metadata的defaultValue来初始化，必须要在类的构造器中初始化（参考[http://msdn.microsoft.com/zh-cn/library/cc903961(v=VS.95).aspx][http_msdn.microsoft.com_zh-cn_library_cc903961_v_VS.95_.aspx]）：

这样就能得到正常结果。但他不明白的是，为什么微软不为这种情况特别处理一下，而要留给开发人员这么一个陷阱？

说实话，我当时被问住了，因为我之前也只是**机械地把结论当做一个开发的“注意事项”记了下来**，至于原因，并没有深思。

\---------------------

其实，从原理上思考一下，并不难得出结论。微软并不是不愿意处理，而是无法处理。

首先，这个问题并不是只有集合类型值才会遇到，所有的引用类型都可能遇到此问题，参考下面的示例：

class Foo : DependencyObject
    {
        public List<int> Bars
        {
            get { return (List<int>)GetValue (BarsProperty); }
            set { SetValue (BarsProperty, value); }
        }
    
        public static readonly DependencyProperty BarsProperty =
            DependencyProperty.Register (
                "Bars",
                typeof (List<int>),
                typeof (Foo),
                new PropertyMetadata (new List<int> ()));
    
        public int Length
        {
            get { return (int)GetValue (LengthProperty); }
            set { SetValue (LengthProperty, value); }
        }
    
        public static readonly DependencyProperty LengthProperty =
            DependencyProperty.Register (
                "Length",
                typeof (int),
                typeof (Foo),
                new PropertyMetadata (5));
    
        public class Data
        {
            public int Value { get; set; }
        }
    
        public Data MyData
        {
            get { return (Data)GetValue (MyDataProperty); }
            set { SetValue (MyDataProperty, value); }
        }
    
        public static readonly DependencyProperty MyDataProperty =
            DependencyProperty.Register (
                "MyData",
                typeof (Data),
                typeof (Foo),
                new PropertyMetadata (new Data () { Value = 3 }));
    }

该类声明了三个DP：List<int>类型的Bars，int类型的Length和自定义类Data类型的MyData，均用DP的defaultValue进行初始化。调试结果如下：

[![image][image 2]][image_image 2]

可见，在foo2刚刚构造完成时，Bars和MyData属性都已经和foo1一致了，使用object.ReferenceEquals比较后证明确实均为同一实例。这也是可以料想到的结果，所谓的“集合”与其他的引用类型相比，并没有什么本质的特殊性。至于为何一般此问题讨论的都是集合的特殊性，以及MSDN上也特别说明是“集合类型”，我想可能是因为DependencyProperty常用的是一些基本的值类型，String虽是引用类型，却是Immutable的，因此也不会出现这个问题；那么要用到引用类型而又可能出问题的，最常见的就是集合类型了，因此MSDN要特别把这个问题拿出来说明一下。

\---------------------

**好，那现在问题变得一般化了：一般的引用类型，为何会存在此“陷阱”？**

我们还需要从DP的原理说起。DP必须定义为静态成员，其本质是静态的哈希表（当然其实际实现要复杂得多，至于为什么这么实现，微软有很多这方面的介绍，比如可以支持资源、样式、动画、数据绑定等等）。而类的每个实例在这张静态表中就有一项，用来记录每个实例对应DP的值，这个值会使用DP的PropertyMetadata所指定的defaultValue进行初始化。我们使用SetValue和GetValue方法，其实就是在对这张表中的对应项进行读写。

说到这里，大家应该都已经明白问题所在了，值类型属性的值就是存储在哈希表中的，因此修改值类型属性不会影响其他实例的相同属性；而引用类型属性在哈希表中存储的只不过是一个引用，初始化为指向同一对象，当对该属性进行修改时（比如向集合中添加元素），其实是向所有实例所共享的对象中添加元素，因此，其他实例的属性也会受到影响。

\---------------------

也许还有人会问，为什么微软不为每个实例初始化一个新的引用对象呢？不错，我也这么想过，但正如我前面所说，**按照现在的设计，微软不一定是没有想到，很可能是做不到**。实际上，在PropertyMetadata对象初始化之前，引用对象已经创建完成了：

new PropertyMetadata (new List<int> ())

思考一下这段代码的运行顺序，在调用PropertyMetadata的构造函数之前，List<int>对象已经构造完成，因此PropertyMetadata拿到的就只是一个引用，它无法知道如何去构造这个引用对象，因此无法为哈希表每项都创建一个新的实例，而只能老老实实地使用手里这个引用。

因此，对于初始值为引用类型的DependencyProperty来说，我们确实只能在类的构造方法中对齐初始化（[虽然微软建议使用PropertyMetadata初始化][PropertyMetadata]）。

Bars = new List<int> ();

等等，别以为这就完了，这里使用了Bars属性，实际上是调用了SetValue方法。那对于readonly的DependencyProperty呢？事实上，在使用集合时，很明显这个属性本身最好是只读的，我们修改的是集合的元素，而不是集合这个属性本身。在WPF中，定义一个只读的DependencyProperty的方法可以参考[这里][Link 1]（SL 4不支持RegisterReadOnly方法，可以自己实现ReadOnly的效果，参考[这篇博客][Link 2]），代码如下：

public List<int> Bars
    {
        get { return (List<int>)GetValue (barsPropertyKey.DependencyProperty); }
    }
    
    private static readonly DependencyPropertyKey barsPropertyKey =
        DependencyProperty.RegisterReadOnly (
            "Bars",
            typeof (List<int>),
            typeof (Foo),
            new PropertyMetadata (null));

此时，使用了私有的DependencyPropertyKey类型字段代替了原来公开的DependencyProperty类型字段，Bars属性也去掉了set方法。那要如何进行初始化呢？

这时，SetValue方法的另一个重载就用上了，这个重载接受一个DependencyPropertyKey而不是一个DependencyProperty，而这正是RegisterOnly方法的返回值。（我原来一直奇怪为什么GetValue只有一个版本而SetValue有两个版本…）

代码如下：

public Foo ()
    {
        SetValue (barsPropertyKey, new List<int> ());
    }

\---------------------

**现在回到原来的问题上。**

对于这样一个“陷阱”，难道真的没有办法？难道必须小心地把初始化放到类实例的构造函数中？

在[Prism][]框架中，当我们向一个Region注册View时，可以使用IRegionManager的扩展方法RegisterViewWithRegion:

public static IRegionManager RegisterViewWithRegion (
        this IRegionManager regionManager, 
        string regionName, 
        Func<object> getContentDelegate);

第三个参数，本应传入要注册的View对象，却传入了一个Func<object>，这是什么意思？我们再看一下实际使用代码：

_regionManager.RegisterViewWithRegion (RegionNames.SidebarRegion,
        () => _container.Resolve<ISidebarPresenter> ().View);

可见，实际传入的是一个匿名委托，这个委托告诉了RegionManager如何创建一个View。RegionManager得到这个委托后，用一个Dictinoary把它保存起来，到实际创建View的时候才去调用。因此\_container.Resolve<ISidebarPresenter> ().View这段代码要到实际创建View时才会运行。同时，RegionManager只需反复调用委托，也具备了重复创建多个View实例的能力。

\---------------------

这样的方法，也许WPF/SL会借鉴一下？或许某一天，我们可以写出这样的代码：

而不用再去担心这样的“陷阱”。

转载于:https://www.cnblogs.com/Gildor/archive/2010/05/24/1742743.html

[76e073b4-59e4-4e46-b97e-3445c93aea76]: /images/20211109/af912a123d6b414a94814ea1e5733335.png
[76e073b4-59e4-4e46-b97e-3445c93aea76 1]: http://images.cnblogs.com/cnblogs_com/Gildor/WindowsLiveWriter/DependencyPropertyDefaultValue_103B1/76e073b4-59e4-4e46-b97e-3445c93aea76_2.png
[image]: /images/20211109/b6ab58bd58e74d05a144bc790afcbe00.png
[image 1]: http://images.cnblogs.com/cnblogs_com/Gildor/WindowsLiveWriter/DependencyPropertyDefaultValue_103B1/image_2.png
[http_msdn.microsoft.com_zh-cn_library_cc903961_v_VS.95_.aspx]: http://msdn.microsoft.com/zh-cn/library/cc903961%28v=VS.95%29.aspx
[image 2]: https://images.cnblogs.com/cnblogs_com/Gildor/WindowsLiveWriter/DependencyPropertyDefaultValue_103B1/image_thumb_2.png
[image_image 2]: /images/20211109/b033bccb22164b91bf70a57a61715d25.png
[PropertyMetadata]: http://msdn.microsoft.com/en-us/library/bb613565.aspx#DPs_and_Objects
[Link 1]: http://msdn.microsoft.com/en-us/library/ms754044.aspx
[Link 2]: http://blogs.msdn.com/delay/archive/2010/03/30/sometimes-you-just-gotta-do-the-best-you-can-tip-read-only-custom-dependencyproperties-don-t-exist-in-silverlight-but-can-be-closely-approximated.aspx
[Prism]: http://compositewpf.codeplex.com/