WPF架构关键技术剖析(2)--XAML、对象序列化、类动态实例化

我们知道对于界面元素的描述，WPF的XAML不是第一个，HTML就要早很多，delphi的dfm也是一种。界面描述和界面交互逻辑的分离是有很多好处的，比如有利于可视化设计，有利于界面复用等。微软总是想一统天下，WPF的出现也是这种理想。当然，这种理想的出现也是有实际需求支持的。对于应用程序架构来说,传统的CS和BS都在相互融合，所以整合这两种模式下的界面设计也有其需求，并有利于两种模式的转换和融合。WPF采用XAML作为UI呈现的描述语言，而作为一种语言，XAML本身并没有什么需要特别关注的东西，我们只要去遵循这种规则即可。XAML语言的基本思想更HTML并无太大的区别，只是采用XML格式，依然遵循树型架构。XAML中的每个UI元素，实际上都代表后台某个UI类的一个实例，因此我们也可以将这个类的实例在XAML中的表示看做是这个实例对象的一种序列化。

对象的序列化，实际上就是将对象的属性（对象静态特征或者动态特征，在实现中包括属性和域),保存为一种特定格式的字节流（也可以是Bit流），以便于存储和传输。而恢复这个对象为内存中的一个实例的过程就是反序列化，反序列化得过程也是对象动态实例化得过程。对于XAML而言更多的是实例化（反序列化），这个需要由XAML解析程序来完成。由于XAML并仅仅只包含属性，还包含事件等特性，因此比单纯的对象序列化要复杂很多，利用传统的对象反序列化还无法达到内存实例化UI元素的目的。但从原理上来讲都差不多，只是XAML的解析规则更为复杂一些。
当然，在程序实际运行时，UI元素对象的特征和行为（方法）还是需要结合在一起，形成一个真正意义上的UI对象实例。由XAML的解析最终生成相应的对象实例的过程，就是对象动态实例化过程。在这里，要生成对象实例，就需要用到反射机制（对于像delphi那样的，是直接由编译器完成解析并编译到执行代码中去，因此并不需要运行时的解析，因此也不需要反射机制，虽然它也有一些现在反射机制的原型）。反射机制包括两部分，一个是元数据，一个是动态实例化。其中元数据记录了类的信息，比如类名，类的成员信息等。动态实例化其实并不复杂，就是动态构造对应对象的（这个信息来自于XAML)的实例，并把从XAML获取的属性信息等利用反射机制中的赋值机制把实例属性等信息完善。如果把表看做是类，表的一条记录类看做是一个对象的话，元数据就类似于表的结构信息，利用表的结构信息，根据提供的信息构造表的一条记录其实就相当于对象的实例化。在dotnet中要动态构造一个类的实例，可以利用Activator的CreateInstance方法，或者利用Assembly类的CreateInstance方法。

XAML解析过程我们虽然并不是很清楚，但也可以利用对象的序列化来理解这种过程，我在前面的博文中有写这部分内容，所以这里不再赘述。但这个过程的理解非常关键，因为很多看起来很神秘，很高深的事情其实都发生在这个过程中。实际上，对于XAML的解析，我们利用VS提供的XML访问加上反射技术，完全可以做出来，只是没什么实际意义而已。

XAML的具体语法规则，大家可以参考相应的文档，说句实话，我也并不是特别的了解，也并不想去死记硬背。因为我们只需要搞清楚这种实现的内在机制即可。

另外大家需要记住，XAML只是UI元素类的属性描述，我们没法用XAML信息去生成一个新的类，这些XAML中的UI元素对应的类都必须存在于后台代码中，我们只是去实例化这个对象。

题外话：定义像XAML这样的一种语言，是非常难的，然而一旦确定这种语言规则，解析和应用本身就不是很难了。这个世界上真正的高手就是这些（游戏）规则的制定者。