剖析WPF数据绑定机制

引言

WPF框架采取的是MVVM模式，也就是数据驱动UI，UI控件（Controls）被严格地限制在表示层内，不会参与业务逻辑的处理，只是通过数据绑定（Data Binding）简单忠实地表达与之绑定的数据。

本文计划从数据端、控件端各自的实现要求，绑定的过程和中介等角度全面地剖析数据绑定的运行机理，帮助读者打开数据绑定的盒子，看到运作的本质，使读者知其然更知其所以然。

一个简单的例子

最开始提供一个简单的数据绑定例子，各环节的功能算是完备，在阅读随时可以回来参考例子理理思路。TextBox绑定一个包装过的字符串，单击按钮改变字符串，TextBox应当相应改变，代码如下。

XAML文件：

    <StackPanel>
       <Button x:Name="b" Content="Change Value" Margin="30" Width="100" Click="b_Click"/>
       <TextBox x:Name="tb" Width="100"/>
    </StackPanel>

C#文件：

    public partial class MainWindow : Window
    {
       private Source s = new Source();
       public MainWindow()
       {
           InitializeComponent();
           Binding binding = new Binding("S");
           binding.Source = s;
           tb.SetBinding(TextBox.TextProperty, binding);
       }
       private void b_Click(object sender, RoutedEventArgs e)
       {
           s.S = "New value";
       }
    }
    class Source:INotifyPropertyChanged
    {
       public event PropertyChangedEventHandler PropertyChanged;
       private string _s = "Old value";
       public string S
       {
           get
           {
              return _s;
           }
           set
           {
              _s = value;
              PropertyChanged.Invoke(this,new PropertyChangedEventArgs("S"));
           }
       }
    }

 

数据端：INotifyPropertyChanged接口

控件要处于一个被动的地位，根据数据的变化来自动做动作，这种多对一的监听很显然属于设计模式中的“订阅/发布模式”（Subscribe/Publish），而.NET C#天然地以事件event支持了这一模式，可以说极大地方便了基于此的数据绑定机制。做一个简单说明：

   

    delegate void Handler();
    class Publisher
    {
       public event Handler Event;
       public void Invoke()
       {
           Event.Invoke();
       }
    }
    class Subscriber
    {
       public void Subscribe(Publisher p)
       {
           p.Event += _callback;
       }
       private void _callback()
       {
           throw new NotImplementedException();
       }
    }
    class Program
    {
       static void Main(string[] args)
       {
           Publisher p = new Publisher();
           Subscriber s = new Subscriber();
           s.Subscribe(p);
           try
           {
              p.Invoke();   
           }catch(NotImplementedException)
           {
              Console.WriteLine("Process normally.");
           }
           Console.ReadKey();
       }
    }

例子中，声明了事件Event，它看做一个委托方法（Delegate method）的集合，订阅者向其中添加自己的回调方法这即是订阅了该事件。

现在考虑WPF数据绑定，数据是事件的发生者即发布者，控件是订阅者，所以数据应该有一个可以触发（Invoke）的事件，在.NET中采用接口（Interface）INotifyPropertyChanged。

这个接口在System.ComponentModel里面，内容很简单：

    public interface INotifyPropertyChanged
    {
       event PropertyChangedEventHandler PropertyChanged;
    }

实现这么个事件即可，委托如下：

public delegate void PropertyChangedEventHandler(object sender, PropertyChangedEventArgs e);

第二个参数也很简单：

    public class PropertyChangedEventArgs : EventArgs
    {
       public PropertyChangedEventArgs(string propertyName);
       public virtual string PropertyName { get; }
    }

只需要提供一个字符串作为属性（Property）名即可。这里可以考虑，实现了这一接口的发布者在数据改变时主动地加一句话去Invoke此事件，注册（按照这里讨论的，就是绑定）了此数据的控件的回调方法会被调用做动作，这就是数据绑定——nice！

请留意，这个接口并非必须实现不可，之后的部分我将提到一种不用实现它的做法。

控件端与属性

C#里对C++这种原始的OOP——方法+字段进行了拓展，把字段的简洁用法和方法的逻辑能力结合，这就叫属性。对于以往的字段，推荐使用属性编写。

请打开Visual Studio，找一个控件类一路上溯它的继承体系，会看到Control类再向上有一个叫做DependencyObject的基类，这是本节研究的重点。

依赖（Dependency）是控件的特点，毕竟数据驱动UI开发，UI是要依赖一些东西的（这里讲的就是数据，依赖来自数据绑定）。

需要介绍和DependencyObject协作的另一个类DependencyProperty，以DependencyObject为主体，通过一系列的方法操作DependencyProperty，比如以下两个：

    public class DependencyObject : DispatcherObject
    {
       //....
       public object GetValue(DependencyProperty dp);
       //....
       public void SetValue(DependencyProperty dp, object value);
       //....
    }

具体的机制我不准备详细介绍，刘铁猛老师的书《深入浅出WPF》中有非常好的讲解。简单来说，DependencyObject应该为DependencyProperty提供一个C#属性作为包装。每个DependencyObject拥有n（n=依赖属性数量）个静态的DependencyProperty实例（此实例由DependencyProperty的静态方法Register得到）而非每个实例拥有一个。每个DependencyProperty实例包含一个广泛的表，作用是通过与C#属性名、属性类型有关的经过哈希运算得到的键来获取需要的，特定实例，特定属性的值，关系可由下图说明：

深入绑定

现在看看控件端特性与数据端特性是如何相互作用的。

专门提供方法的静态类（Static class）BindingOperations有静态方法SetBinding,基类FrameworkElement有对其的同名封装，控件就是通过这个函数和数据实现绑定的，下面研究一下这个没有封装的原始形式。

        public static BindingExpressionBase SetBinding(DependencyObject target, DependencyProperty dp, BindingBase binding);

先看一下第三个参数，再回头看看前两个参数和控件端相关的。

1.  BindingBase是一个抽象类（Abstract class），内部有抽象方法CreateBindingExpressionOverride由它的子类实现，明确了数据来源的子类完成创建BindingExpressionBase的工作。

2.  由上图可以清晰地看出，DependencyObject和DependencyProperty并非包含关系而是相依的，你需要同时提供两个才能明确哪个控件的哪个依赖属性需要绑定。

Binding对象是面向数据侧的，这很好理解，支持了多个控件绑定同一数据。

那么一次SetBinding究竟做了什么？它的返回值是BindingExpressionBase，它有三个子类分别是BindingExpression，MultiBindingExpression，PriorityBindingExpression，在此只研究简单的目标绑定单源，即用BindingExpression子类。一个绑定数据的Binding可以多次与控件绑定，每次返回一个新的BindingExpression，那么很好理解，它就是一组绑定的实例，它与Binding是多对一的关系。可以把Binding看做一个通电的插排，不断有充当插头的DependencyObject来对接（绑定），而返回的BindingExpression就是真正可用的配合。它继承并重写了BindingExpressionBase的UpdateTarget和UpdateSource方法——至此，Binding的地位和作用开始明确了：

UpdateSource只在TwoWay和OneWayToSource模式下有效，这里以UpdateTarget这个通用的方法说明这对“更新方法”。每一组绑定有一个BindingExpression实例，SetBinding的作用正是将更新方法写进数据源INotifyPropertyChanged接口的事件委托之中，当事件触发，即数据发生改变时调用注册的回调来更新Target控件——毕竟更新方法是public方法，随时可以手工调用只是什么都不会发生罢了（当数据源没有实现INotifyPropertyChanged等通知接口时可以这样强制更新，但这是舍弃了自动的连贯行为，转为手工实现）。

注意，BindingExpression还实现了接口IWeakEventListener，这是关于.NET的弱事件模式（Weak event pattern）。通常，监听者注册事件会在事件源内存放一个自己的引用，而如果不显式地删除这个引用，即使监听者生命周期早已结束，引用仍然存在，GC不会进行——这就造成了一种形式的内存泄漏。数据绑定符合这个场景。.NET给出的解决方法是弱事件模式。在这个模式中，事件源端实现一个WeakEventManager，监听端实现接口IWeakEventListener，这样注册到源的事件处理方法进传递一个弱引用，这不会无限延长监听者的生命周期。

属性与反射的应用

C#的反射技术给动态访问类的属性提供了可能。通过类似这样的代码：

    MyClass mc = new MyClass();
    mc.GetType().GetProperty("MyProperty").SetValue(mc, 1);

我们得以通过传递字符串的方式标记指定类的指定属性。本节的目的是串联之前各部分，看看方法的参数用意何为，看看反射是怎么贯穿数据绑定机制的环节之间的。

约定数据源包装实际数据，通过属性暴露出来，在属性改变时激发事件PropertyChanged。如之前讲的，这个事件激发的参数是表明此属性的字符串。现在，属性名已经分发到了每个有关此数据的BindingExpression上。要注意，数据源只有独一个PropertyChanged事件，所有属性更改都会激发它（为什么只一个？这是INotifyPropertyChanged接口规定的啊），所以绑定此数据源的所有Binding都会接到通知（Notify），它们需要鉴别。通过public属性ResolvedSource和ResolvedSourcePropertyName可知，它确实有了识别属性的足够信息，于是它们分别对照Invoke时PropertyChangedEventArgs附加的属性名看是不是自己关联的，最终只有一个Binding确认自己绑定了这个属性，然后它UpdateTarget——这关键一步通过上面示范的反射机制即可胜任。

这就是属性名从特定属性内部流出直到指导控件更新的过程，可谓环环相扣精巧严密。

 

 

局限于篇幅，我不能事无巨细地说明每一个细节，请读者对想深入理解的点查阅更多的资料，定会收获良多。