使用哪种风格的 API 取决于具体情况。和基于指针的 API 相比，基于事件迭代器的 API 具有更多的面向对象特征。因此更便于应用于模块化的体系结构，因为当前的解析器状态反映在事件对象中，应用程序组件在处理事件的时候不需要访问解析器/读取器。此外，还可以使用 XMLInputFactory 的 createXMLEventReader(XMLStreamReader) 方法从 XMLStreamReader 创建 XMLEventReader。

　　StAX 还定义了一种序列化器 API，Java 标准 XML 处理支持中一直缺少的一种特性。和解析一样，也包含两种风格的流式 API：处理标记的底层 XMLStreamWriter 和处理事件对象的高层 XMLEventWriter。XMLStreamWriter 提供了写入单个 XML 记号(比如开始和关闭标记或者元素属性)的方法，不检查这些标记是否格式良好。另一方面，XMLEventWriter 允许应用程序向输出中添加完整的 XML 事件。

　　为什么使用 StAX?

　　开始学习一种新的处理 XML 的 API 之前，可能要问是否值得这样做。事实上，StAX 所采用的基于拉的方法和其他方法相比有一些突出的优点。首先，不管使用哪种 API 风格，都是应用程序调用读取器(解析器)而不是相反。通过保留解析过程的控制权，可以简化调用代码来准确地处理它预期的内容。或者发生意外时停止解析。此外，由于该方法不基于处理程序回调，应用程序不需要像使用 SAX 那样模拟解析器的状态。

　　StAX 仍然保留了 SAX 相对于 DOM 的优点。通过把重心从结果对象模型转移到解析流本身，从理论上说应用程序能够处理无限的 XML 流，因为事件固有的临时性，不会在内存中累积起来。对于那些使用 XML 作为消息传递协议而非表示文档内容的那些应用程序尤其重要，比如 Web 服务或即时消息应用程序。比方说，如果只是将其转换成特定于应用程序的对象模型然后就将其丢弃，那么为 Web 服务路由器 servlet 提供一个 DOM 就没有多少用处。使用 StAX 直接转化成应用程序模型效率更高。对于 Extensible Messaging and Presence Protocol(XMPP)客户机，根本不能使用 DOM，因为 XMPP 客户机/服务器流是随着用户输入的消息实时生成。等待流的关闭标签(以便最终建立 DOM)就意味着等待整个会话结束。通过把 XML 作为一系列的事件来处理，应用程序能够以最合适的方式响应每个事件(比如显示收到的即时消息等等)。

　　由于其双向性，StAX 也支持链式处理，特别是在事件层上。接收事件(无论什么来源)的能力被封装在 XMLEventConsumer(XMLEventWriter 的扩展)接口中。因此，可以模块化地编写应用程序从 XMLEventReader(也是一个普通的迭代器，可以按迭代器处理)读取和处理 XML 事件、然后传递给事件消费者(如果需要可以进一步扩展处理链)。在第 2 部分将看到，也可使用应用程序提供的筛选器(实现了 EventFilter 接口的类)来定制 XMLEventReader 或者使用 EventReaderDelegate 修饰已有的 XMLEventReader。

　　总而言之，和 DOM 以及 SAX 相比，StAX 使应用程序更贴近底层的 XML。使用 StAX，应用程序不仅可以建立需要的对象模型(而不需要处理标准 DOM)，而且可以随时这样做，而不必等到解析器回调。

……