深入浅出WPF（9）——数据的绿色通道，Binding（下）

 深入浅出WPF（9）——数据的绿色通道，Binding（下）

 

小序：

看着自己上一篇技术文章，屈指算来，已经月余没有动笔了——实在是不像话。最近一来是忙工作，二来是兴趣点放在了设计模式上，而且尝试着把设计模式也“深入浅出”了一把，当然啦，因为对于design pattern我也是初学，在没有经过大家检验之前我是不敢拿到blog里丢人现眼滴~~~现在项目组里由喵喵同学、美女燕、大马同学和小马同学一同push一个“设计模式沙龙”，大家一起学习和讨论这些模式和如何应用在我们的项目里做重构。等活动结束后，我心里有底了，就把文章放上来:)

 

N久不动笔了……上回写到哪儿了？呃~~~咱们继续吧！

 

正文

如果用一句话概括前几篇关于data binding的文章，那就是：介绍了数据驱动（界面）开发的基本原理，以及如何使用Binding类的实例连接数据源与数据表现元素、形成一对一的binding（为了让数据有效、安全，我们还可以添加Converter和ValidationRule等附件）。

 

注意啦，我强调了一下——是一对一的binding哦！也就是说，一个binding实例一端是数据源、一端是表现元素。现在问题来了：实际工作中，我们操作的大部分数据都是集合，怎么进行“群体binding”呢？呵呵，这就引出了我们今天的第一个topic——对集合进行binding。

 

集合Binding揭秘

我们想这样一个问题——如果我有一个List<Student>的实例，里面装着二十个Student对象，现在我想让一个ListBox显示出学生的Name，并且当集合中有Student对象的Name发生改变时，ListBox的Item也立刻显示出来，应该怎么做呢？

有人会说：那还不好办？做一个循环，按照集合元素的数量生成相应多的ListBoxItem，并把每个ListBoxItem的Text属性（如果有）用Binding一对一连接到List中的Student对象上不就结了？

我没试过这样行不行，但我知道，这违反了“数据驱动UI”的原则——请记住，在WPF开发时，不到万不得已，不要去打UI元素的主意、不要把UI元素掺合进任何运算逻辑。拿上面的例子来说，手动地去生成ListBoxItem就已经超越了“数据驱动UI”的限制，是不恰当的作法。

OK，让我们看看微软提供的“正宗集合binding”吧！

首先我们得准备一个用来存放数据的集合，对于这个集合有一个特殊的要求，那就是，这个集合一定要是实现了IEnumerable接口的集合。为什么呢？原因很简单，实现了IEnumerable接口就意味着这个集合里的元素是可枚举的，可枚举就意味着这个集合里的元素是同一个类型的（至少具有相同的父类），元素是同一个类型的就意味着在每个元素中我都能找到同样的属性。举个例子，如果一个实现了IEnumerable的集合里装的是Student元素，这就意味着每个元素都有诸如ID、Name、Age等属性，对于任何一个元素我都不会找不到ID、Name或者Age——不然就没办法“批量binding”了；如果一个实现了IEnumerable接口的集合里除了有Student对象，还有Teacher对象、Programmer对象，怎么办呢？这时候，这个集合肯定只能拿Student、Teacher、Programmer的共同基类来进行枚举了，假设它们的共同基类是Human，那Human至少会有Name和Age属性吧——我们可以拿这两个属性去做binding的Path，而集合里的每一个元素都作为一个独立的数据源。

下面我给出核心代码。

 

首先我们准备了一个Student类，包含StuNum、Name、Age三个属性，

class Student
{
    public int StuNum { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
}

然后我们在Window的Grid元素里添加一个ListBox，这个操作是在XAML文件里做的：

 

 

显示出来的效果是这样的：

 

 

接下来，我们使用集合binding，让ListBox把学生的名字显示出来。为了方便起见，我把逻辑代码写在了Window的构造函数里，请大家注意——做项目的时候要尽量保持构造函数里的“干净”，很多很多紧耦合都是不小心在构造函数里“创造”出来的。

 

1. //水之真谛出品
2. // http://blog.csdn.net/FantasiaX
4. public Window1()
5. {
6.     InitializeComponent();
7.     List<Student> stuList = new List<Student>() 
8.     {
9.         new Student{StuNum=1, Name="Tim", Age=28},
10.         new Student{StuNum=2, Name="Ma Guo", Age=25},
11.         new Student{StuNum=3, Name="Yan", Age=25},
12.         new Student{StuNum=4, Name="Xaiochen", Age=28},
13.         new Student{StuNum=5, Name="Miao miao", Age=24},
14.         new Student{StuNum=6, Name="Ma Zhen", Age=24}
15.     };
17.     this.listBox1.ItemsSource = stuList;
18.     this.listBox1.DisplayMemberPath = "Name";
19. }

立竿见影地说，你马上就能看到效果：

 

 

其实，最有用的就是最后两句代码：

this.listBox1.ItemsSource = stuList;一句的意思是告诉ListBox说：stuList这个集合里的元素就是你的条目啦！也就是说，stuList就等同于listBox1.Items了。集合对集合，意味着两个集合里的元素也将一一对应。

显然，stuList集合里的元素是ListBox.Items集合里元素的数据源，两个集合里的元素一一对应。

还有一句，this.listBox1.DisplayMemberPath = "Name";，是告诉ListBox说，你的每个条目不是要显示点东西给用户看吗？那你就显示“Name”属性的值吧！

你可能会问：它怎么知道去找Student对象的Name属性呀？你想呀，前面说过，能用于做数据源的集合一定实现了IEnumerable接口（List<>就实现了这个接口），也就是说，我可以枚举出一个一个的Student对象，又因为每个Items里的元素都与stuList里的一个Student对象一一对应、每个Student对象肯定有Name属性，so