引言
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——这关键一步通过上面示范的反射机制即可胜任。
这就是属性名从特定属性内部流出直到指导控件更新的过程，可谓环环相扣精巧严密。
局限于篇幅，我不能事无巨细地说明每一个细节，请读者对想深入理解的点查阅更多的资料，定会收获良多。