因为XAML是设计用来与.NET类型系统一起工作的，你可以在其中使用任何类型的.NET
对象（甚至是COM对象，这还多亏了COM的互操作性），也可以使用自己定义的对象，无论这
些对象是不是与用户界面有关。但是，对象必须以“友好声明”（declarative-friendly）的方式
进行设计。例如，如果一个类没有默认的构造函数，也没有提供有用的实例属性，那么它在
XAML中是无法直接使用的。设计WPF API有很多细节来适应XAML的声明模型，它超越了通
常.NET的设计规范。
WPF 程序集都被加上了XmlnsDefinitionAttribute属性，这样可以将.NET命名空间映射
为XAML文件中的XML命名空间，但是对于那些不是专门为XAML设计的程序集又该如何处
理呢？不使用这个特性吗？它们的类型仍然可以使用，只需要使用一个特殊的指令作为XML
命名空间就可以了。例如，下面有一些普通、陈旧的C#代码，使用了包含在mscorlib.dll中
的.NET Framework API：
以上代码在XAML中表示为：
clr-namespace标记允许直接在XAML中放入一个.NET命名空间。仅当需要的类型不在相同的
程序集（XAML编译后生成的）中时，最后的程序集规范才是必须的。一般使用程序集的简单
名称（如mscorlib）。但你可以使用规范的呈现方式，它是由System.Reflection.Assembly.Load
提供支持的（虽然不允许空格），该函数包含了额外的信息，如版本或公共密钥令牌。
这个例子有两个关键点强调了不仅与.NET类型系统进行整合，也要与.NET Framework基
类库中的特定类型进行整合。
子元素可以使用标准的XAML x:Key语法添加到父Hashtable中，因为Hashtable和.NET
Framework中的其他集合类从1.0版本开始就实现了IDictionary接口。
之所以可以这么直接使用System.Int32，是因为类型转换器已经存在，且类型转换器是
支持将字符串转换为整型的。因为XAML支持的类型转换器都是派生自System.Component-
Model.TypeConverter的类，这个类从.NET Framework 1.0开始就有了。这其实也是
Windows Forms使用的类型转换机制（例如，允许在Visual Studio的属性格中输入字符串，
并将它们转换为适当的类型）。
对象元素的子元素的XAML处理规则
你现在已经看过3种类型的对象元素的子元素了。为了避免混淆，当转换子元素时，任何一个
有效的XAML解析器或者编译器必须遵循下面的规则：
(1) 如果该类型实现了IList接口，就为每个子元素调用IList.Add。
(2) 否则，如果该类型实现了IDictionary，就为每个子元素调用IDictionary.Add，在该
值的键和元素中使用x:Key特性值。
(3) 否则，如果父元素支持内容属性（由System.Windows.Markup.ContentPropertyAttribute
表示），而且子元素的类型与该内容属性是兼容的，就把子元素作为它的值。
(4) 否则，如果子对象是普通文本，且有类型转换器将子对象转换为父类型（没有在父元
素上设置属性），则把子元素作为类型转换器的输入，将输出作为父对象的实例。
(5) 其他情况下，则抛出一个错误。