在客户端使用 JSON
处理的最后一步是把在客户端把 JSON 数据变成 JavaScript 对象。这可以通过对 eval() 的简单调用实现，这个函数可以即时地解释包含 JavaScript 表达式的字符串。清单 11 把 JSON 响应转变成 JavaScript 对象图，然后执行清单 5 的任务，从顾客的最后一次订单中得到第一个商品的名称。
清单 11. 评估 JSON 响应
var jsonExpression = "(" + req.responseText + ")";
var customer = eval(jsonExpression);
// Find name of first item in customer's last order
var lastOrder = customer.orders[customer.orders.length-1];
var name = lastOrder.items[0].name;
比较清单 11 和 清单 5 可以发现使用 JSON 的客户端的优势。如果在 Ajax 项目中要在客户端对许多复杂的服务器响应进行导航，那么 JSON 可能适合您的需要。JSON 和 XMLHttpRequest 结合还会让 Ajax 交互看起来更像 RPC 调用而不是 SOA 请求，这对应用程序的设计可能会有意义。在下一篇文章中，我要研究的框架，就是明确地为了让 JavaScript 代码对服务器端对象进行远程方法调用而设计的。
JSON 的不足
JSON 也有它的不足。使用这里介绍的 JSON 方式，就没有办法针对每个请求对对象的序列化进行裁剪，所以不需要的字段可能经常会在网络上发送。另外，添加 toJSONObject() 方法到每个 JavaBean，可伸缩性不太好，虽然用内省和标注编写一个通用的 JavaBean 到 JSON 的序列化器可能很简单。最后，如果服务器端代码是面向服务的，没有单独针对处理 Ajax 客户请求调整过，那么由于对 XML 一致的支持，XML 会是更好的选择。
比较序列化技术
现在已经看到了把 Java 状态传输到 Ajax 客户端的五种不同技术。我讨论了自行手工编码 XML 序列化、通过代码生成的 XML 绑定、通过映射机制的 XML 绑定、基于模板的 XML 生成以及手工编码到 JSON 的序列化。每种技术都有自己的优势和不足，分别适用于不同的应用程序架构。
为了总结每种方式的优势与不足，表 1 从六个方面进行了粗略的评分：
可伸缩性
描述技术适应大量数据类型的容易程度。对于每个附加类型，编码和配置工作量是否会增长？
易于集成
评估把技术集成到项目的简单程度。是否需要更加复杂的构建过程？是否增加了部署的复杂性？
Java 类 API
描述以指定方式处理服务器端 Java 对象的容易程度。是可以编写普通的 bean，还是不得不处理笨拙的文档表示？
对输出的控制
描述对类的序列化表示控制的精确程度。
视图灵活性
评估从同一组对象是否可以创建不同的、定制的数据序列化。
客户端数据访问
描述 JavaScript 代码处理服务器响应数据的难易程度。
