Silverlight/WPF中DependencyProperty使用陷阱一枚
今天有朋友写Silverlight代码遇到一个问题，让我一起看一下。这是他写的一个测试类：
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> ()));}
使用代码如下：
可见，当foo2刚刚创建时，Bars中已经有一个元素了。
SL/WPF达人们看到这里肯定已经笑了，我刚开始学习DependencyProperty时也曾在这个问题上卡住。
在Immediate Window中测试foo1与foo2的Bars属性：
果然，Bars其实是同一个List<int>对象。
朋友说，我上网查了，已经知道像List这些集合类属性不能用DependencyProperty Metadata的defaultValue来初始化，必须要在类的构造器中初始化（参考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 (null)); public Foo () { Bars = new List<int> (); }}
这样就能得到正常结果。但他不明白的是，为什么微软不为这种情况特别处理一下，而要留给开发人员这么一个陷阱？
说实话，我当时被问住了，因为我之前也只是机械地把结论当做一个开发的“注意事项”记了下来，至于原因，并没有深思。
---------------------
其实，从原理上思考一下，并不难得出结论。微软并不是不愿意处理，而是无法处理。
首先，这个问题并不是只有集合类型值才会遇到，所有的引用类型都可能遇到此问题，参考下面的示例：
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进行初始化。调试结果如下：
可见，在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初始化）。
Bars = new List<int> ();
等等，别以为这就完了，这里使用了Bars属性，实际上是调用了SetValue方法。那对于readonly的DependencyProperty呢？事实上，在使用集合时，很明显这个属性本身最好是只读的，我们修改的是集合的元素，而不是集合这个属性本身。在WPF中，定义一个只读的DependencyProperty的方法可以参考这里（SL 4不支持RegisterReadOnly方法，可以自己实现ReadOnly的效果，参考这篇博客），代码如下：
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会借鉴一下？或许某一天，我们可以写出这样的代码：
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> ()));}
而不用再去担心这样的“陷阱”。
