2.9  小结

你已经看到了XAML是如何与WPF配合的，最重要的是，你现在已经有足够的知识来把大多数的XAML实例转换为一种语言，如C#，也可以把一种语言转换为XAML。然而，因为类型转换器和标记扩展是“黑盒”，直接翻译或转换是不太可能的。也就是说，如果你不能理解在内部转换是如何进行的也没有关系，因为从过程式代码中直接调用类型转换器是可选的。（许多拥有对应的类型转换器的类会提供一个静态的Parse方法，做的是同样的事情，这是为了简化过程式代码才加进去的。）

这些本应该在XAML中特别处理的简单概念（如null），使用了第三方用的相同的标记扩展机制来表示，所以我很喜欢。它将XAML语言变得尽可能地简单，并保证了可扩展机制可以很好地运作。

进一步了解WPF之后，你可能会发现，一些WPF API在过程式代码中调用有些不方便，因为它们的设计经常为XAML使用而优化的。例如，WPF提供了许多小型构建块[在第1章中讲到，这些构建块可以帮助你完成富创作（rich composition）]，因此WPF应用程序通常必须比像Windows Forms这样的应用程序手工创建更多的对象。除了XAML在简练表现对象的深度层次方面更加出色以外，WPF团队花了很多时间来实现在XAML中高效隐藏过渡对象（如类型转换器）的功能，而不是在过程式代码中隐藏它们（例如，创建内部对象的构造函数）。

大多数人理解WPF由XAML提供单独的声明型换型的好处，但有些人也为把XML作为所选格式而痛惜。下面有两段常见的抱怨，我来说说。

2.9.1  抱怨1：XML太过冗长不便于输入

确实如此！几乎没有人喜欢输入很多XML，但其实有许多工具。附录中列出了一些可以减少大量输入的工具。可以基于XML Schema定义（XSD）以自动完成拼写的形式完成，还有一些可视化设计器不需要你一个个输入尖括号。XML的透明性和明确性使得开发过程中引入新工具变得很简单（例如，你可以为最喜欢的工具创建一个XAML导出器），也使定制或者故障排除变得简便。

在WPF的某些领域，如遇有复杂的路径和形状、3D模型等，手工输入XAML是不现实的。事实上，当XAML第一次在beta版中被引入的时候，这种将一些人工输入的快捷方式移除的趋势已经形成，这样有利于促进格式的可预测性和可扩展性，从而得到更好的工具支持。但是我仍然相信通过熟透XAML，从过程化和声明式的观点看WPF API是学习这项技术的最好方式，这就像在不依靠FrontPage这样的工具的情况下理解HTML一样。

2.9.2  抱怨2：基于XML的系统性能差

XML是改进互操作性的格式，而不是用于数据高效呈现的。那么，为什么大多数WPF应用程序可以承受巨大而又解析较慢的数据呢？

好在一般的WPF方案中，XAML是被编译为BAML的，因此不需要对大小和运行时的解析性能付很高的代价。BAML比原来的XAML文件要小，并对运行时的性能做了优化。因此，XML的性能缺陷通常只会影响开发时，而此时又是最需要XML的好处的。