这种类型的 XML 绑定框架在数据拆解时最有用(例如,使用 XML 文档并把它们转化成 Java 对象)。除非拥有大型数据模型而且有可能从生成的类中获益,否则基于代码生成的框架对于 Ajax 应用程序来说可能有很大的杀伤力。
映射方式
采用映射方式的框架包括 Castor 和 Apache Commons Betwixt。映射通常是比代码生成更灵活和更轻量的解决方案。首先,可以像通常一样编写 JavaBean,包括任何行为以及任何自己喜欢的方便的方法。
然后,在运行时,调用框架中基于内省的编排器,并根据对象成员的类型、名称和值生成 XML 文档。通过定义类的映射文件,可以覆盖默认的绑定策略,并就类在 XML 中的表示方式对编排器提出建议。
这种方法是在可伸缩性与灵活性之间的良好折中。可以按照自己喜欢的方式编写 Java 类,编排器负责处理 XML。虽然映射定义文件编写起来简单,可伸缩性也足够好,但是映射规则最多只能改变标准的绑定行为,而且在对象结构和它们的 XML 表示之间总要残留一些耦合。最终,可能不得不在 Java 表示或 XML 格式之间任选一个做些折中,才能让映射方法起作用。
数据绑定总结
Dennis Sosnoski 就 XML 数据绑定 API 的主题,在代码生成和代码映射两个方面写了深入的文章。如果想进一步研究这个领域,我推荐他在 Castor 和代码生成框架方面的精彩文章。
总之,代码生成方式损失了过多的灵活性和方便性,对于典型的 Ajax 应用程序用处不大。另一方面,基于映射的框架可能工作得很好,但是要恰到好处地调整它们的映射策略,以便从对象生成需要的 XML。
所有的 XML 绑定 API 都具有手工序列化技术的一个主要不足:模型和视图的耦合。被限制为一个类型一个 XML 表示,就意味着在网络上总要有冗余数据传输
在传统的 Web 应用程序开发中,采用页面模板系统把视图生成与控制器逻辑和模型数据干净地分离。这种方法在 Ajax 场景中也会有帮助。
页面模板系统
任何通用目的的页面模板技术都可以用来生成 XML,从而使 Ajax 应用程序根据自己的数据模型生成任何 XML 响应文档。
额外收获是:模板可以用简单的、表现力强的标记语言编写,而不是用一行行的 Java 代码编写。清单 5 是一个 JSP 页面,采用了 Customer bean 并表示出定制的 XML 视图,适合客户端代码生成订单历史组件。
清单 4. 生成订单历史文档的 JSP
value="${requestScope.customer}"/>
"${cust.username}">
"${cust.orders}">
"${order.formattedCost}">
${order.date}
"${order.items}">
escapeXml="true"/>
${item.formattedPrice}
这个简洁的模板只输出订单历史视图需要的数据,不输出不相关的资料(例如商品说明)。创建产品搜索视图的定制 XML 应当同样简单,这个视图包含每个商品的完整说明和库存水平。
模板的问题
另一方面,现在我需要为每个不同视图创建一个新 JSP,而不能仅仅把需要的对象图组织起来并序列化它。从设计的角度来说,许多人可能会有争议,认为这无论如何是件好事,因为这意味着正式地考虑服务器要生成的文档类型。而且,因为我现在要处理通用的模板环境,而不是特定于 XML 的 API,所以确保标记匹配、元素和属性的顺序正确以及 XML 实体(例如 < 或 &)正确转义就成了我的责任
JSP 的核心 out 标记使后面这项工作变得很容易,但是不是所有的模板技术都提供了这样的机制。最后,没有方便的途径可以在服务器端根据方案检验生成的 XML 文档的正确性,但这毕竟不是要在生产环境中做的事,可以方便地在开发期间处理它。
不用 XML 的响应数据
迄今为止,我介绍的所有技术都用 XML 文档的形式生成服务器响应。但是,XML 有一些问题。其中一个就是延迟。浏览器不能立即解析 XML 文档并生成 DOM 模型,所以这会降低某些 Ajax 组件需要的“迅捷”感,特别是在较慢的机器上解析大型文档的时候更是如此。
“现场搜索”就是一个示例,在这种搜索中,当用户输入搜索术语时,就会从服务器提取搜索结果并显示给用户。对于现场搜索组件来说,迅速地响应输入是非常重要的,但是同时它还需要迅速而持续地解析服务器的响应。
延迟是一个重要的考虑因素,但是避免使用 XML 的最大原因是差劲的客户端 DOM API。清单 5 显示了使用跨浏览器兼容的方式通过 DOM 得到某个值的时候,通常不得不面对的困难。
清单 5. 在 JavaScript 中导航 XML 响应文档
// Find name of first item
in customers last order
var orderHistoryDoc = req.responseXML;
var orders =
orderHistoryDoc.getElementsByTagName("order");
var lastOrder =
orders[orders.length - 1];
var firstItem =
lastOrder.getElementsByTagName("item")[0];
var itemNameElement =
firstItem.firstChild;
var itemNameText =
itemNameElement.firstChild.data
当元素中间存在空白时,情况就变得更加复杂,因为每个元素的 firstChild 经常是个空白文本节点。
现在有 JavaScript 库可以缓解处理 XML 文档的麻烦。这些库包括 Sarissa 和 Google-ajaXSLT,这两个库都把 XPath 功能添加到了大多数浏览器中。
但是,想想替代方案还是值得的。除了 responseXML 之外,XMLHttpRequest 对象还提供了名为 responseText 的属性,这个属性只是以字符串的方式提供服务器的响应体。
responseText 属性
当服务器需要向客户机发送非常简单的值时,responseText 特别方便,它可以避免 XML 导致的带宽支出和处理支出。例如,简单的 true/false 响应可以由服务器以纯文本方式返回,可以是逗号分隔的简单的名称或数字列表。
但是,一般来说,最好不要在同一个应用程序中把 XML 响应和纯文本响应混合使用;保持单一数据格式可以让代码抽象和重用更加简单。
responseText 与 XML 响应数据结合时也会有用。在只需要从响应文档中提取单一值的场景中,“欺骗性”地把 XML 当作文本字符串,而不把它当作结构化的文档对待,会更方便。
例如,清单 6 显示了如何用正则表达式从顾客的订单历史中提取第一笔订单的日期。不过,这实际是种花招,一般不应当依赖 XML 文档的词汇表达。
清单 6. 用正则表达式处理 XMLHttpRequest 的 responseText 对象
var orderHistoryText =
req.responseText;
var matches =
orderHistoryText.match
(/(.*?)</date>/);
var date = matches[1];在某些情况下,采用即时方式使用 responseText 会比较方便。但是,理想情况下,应当有种途径,可以用一种能够让 JavaScript 轻松导航、却没有 XML 处理支出的格式表示复杂的结构化数据。幸运的是,确实存在这样一种格式
JavaScript 对象标注
实际上,JavaScript 对象的大部分都由联合数组、数字索引数组、字符串、数字或者这些类型的嵌套组合而成。因为所有类型都可以用 JavaScript 直接声明,所以可以在一条语句中静态地定义对象图。
清单 7 使用 JSON 语法声明了一个对象,并演示了如何访问这个对象。大括号表示联合数组(即对象),它的键 -值组合由逗号分隔。方括号表示数字索引数组。
清单 7. 用 JSON 在 JavaScript 中直接声明一个简单对象
var band =
{
name: "The Beatles",
members: [
{
name: "John",
instruments:
["Vocals","Guitar","Piano"]
},
{
name: "Paul",
instruments:
["Vocals","Bass","Piano","Guitar"]
},
{
name: "George",
instruments:
["Guitar","Vocals"]
},
{
name: "Ringo",
instruments:
["Drums","Vocals"]
}
]
};
// Interrogate the band object
var musician = band.members[3];
alert( musician.name
+ " played " +
musician.instruments[0]
+ " with " +
band.name );
既然 JSON 是一个有趣的语言特性,那么它对 Ajax 有什么意义呢?妙处在于可以用 JSON 在 Ajax 服务器响应中通过网络发送 JavaScript 对象图
这意味着在客户端可以避免使用笨拙的 DOM API 对 XML 进行导航 —— 只需要分析 JSON 响应,就会立即得到可以访问的 JavaScript 对象图。但是,首先需要把 JavaBean 变成 JSON。
从 Java 类产生 JSON
不同 XML 生成技术所具有的优缺点也适用于 JSON 的产生。而且可以证明,存在需要再次使用表示模板技术的情况。但是,使用 JSON 在理念上更接近于在应用层之间传递序列化的对象,而不是创建应用程序状态的视图。
我将介绍如何用 org.json 这个 Java API 在 Java 类上创建 toJSONObject() 方法。然后,就可以把 JSONObject 简单地序列化成 JSON。清单 8 反映了 清单 1 讨论的 XML,显示了 Order 类的 toJSONObject() 实现。
清单 8. Order 类的 toJSONObject() 方法实现
public JSONObject toJSONObject()
{
JSONObject json = new JSONObject();
json.put("id",id);
json.put("cost",getFormattedCost());
json.put("date",date);
JSONArray jsonItems = new JSONArray();
for (Iterator iter =
items.iterator() ; iter.hasNext() ; )
{
jsonItems.put(iter.next().toJSONObject());
}
json.put("items",jsonItems);
return json;
}
可以看到,org.json API 非常简单。 JSONObject 代表 JavaScript 对象(即联合数组),有不同的 put() 方法,方法接受的 String 键和值是原生类型、String 类型或其他 JSON 类型。
JSONArray 代表索引数组,所以它的 put() 方法只接受一个值。请注意在清单 8 中,创建 jsonItems 数组,然后再用 put() 把它附加到 json 对象上;可以用另外一种方法做这项工作,就是对每个项目调用
json.accumulate("items",
iter.next().toJSONObject());accumulate() 方法与 put()类似,区别在于它把值添加到按照键进行识别的索引数组。清单 9 显示了如何序列化 JSONObject 并把它写入 servlet 响应。
清单 9. 从 JSONObject 生成序列化的 JSON 响应
public void doGet(HttpServletRequest req,
HttpServletResponse res)
throws java.io.IOException,
ServletException
{
String custId =
req.getParameter("username");
Customer customer =
getCustomer(custId);
res.setContentType("application/x-json");
res.getWriter().print
(customer.toJSONObject());
}可以看到,它实际上什么也没有做。在这里隐式调用的 JSONObject 的 toString() 方法做了所有工作。请注意,application/x-json 内容类型还有一点不确定 —— 在编写这篇文章的时候,关于 JSON 应当属于什么 MIME 类型还没有定论。但是,目前 application/x-json 是合理的选择。清单 10 显示了这个 servlet 代码的示例响应。
清单 10. Customer bean 的 JSON 表示
{
"orders":
[
{
"items":
[
{
"price": "$49.99",
"description": "
512 Megabyte Type 1 CompactFlash card.
Manufactured by Oolong Industries",
"name": "Oolong 512MB CF Card",
"id": "i-55768"
},
{
"price": "$299.99",
"description": "
7.2 Megapixel digital camera featuring six
shooting modes and 3x optical zoom. Silver.",
"name": "Fujak Superpix72 Camera",
"id": "i-74491"
}
],
"date": "08-26-2005",
"cost": "$349.98",
"id": "o-11123"
}
],
"realname": "James Hyrax",
"username": "jimmy66"
}
在客户端使用 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 customers 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 请求,这对应用程序的设计可能会有意义。
JSON 的不足
JSON 也有它的不足。使用这里介绍的 JSON 方式,就没有办法针对每个请求对对象的序列化进行裁剪,所以不需要的字段可能经常会在网络上发送。
另外,添加 toJSONObject() 方法到每个 JavaBean,可伸缩性不太好,虽然用内省和标注编写一个通用的 JavaBean 到 JSON 的序列化器可能很简单。最后,如果服务器端代码是面向服务的,没有单独针对处理 Ajax 客户请求调整过,那么由于对 XML 一致的支持,XML 会是更好的选择。
比较序列化技术
现在已经看到了把 Java 状态传输到 Ajax 客户端的五种不同技术。我讨论了自行手工编码 XML 序列化、通过代码生成的 XML 绑定、通过映射机制的 XML 绑定、基于模板的 XML 生成以及手工编码到 JSON 的序列化。
每种技术都有自己的优势和不足,分别适用于不同的应用程序架构。为了总结每种方式的优势与不足,表 1 从六个方面进行了粗略的评分:
可伸缩性
描述技术适应大量数据类型的容易程度。对于每个附加类型,编码和配置工作量是否会增长?
易于集成
评估把技术集成到项目的简单程度。是否需要更加复杂的构建过程?是否增加了部署的复杂性?
Java 类 API
描述以指定方式处理服务器端 Java 对象的容易程度。是可以编写普通的 bean,还是不得不处理笨拙的文档表示?
对输出的控制
描述对类的序列化表示控制的精确程度。
视图灵活性
客户端数据访问
描述 JavaScript 代码处理服务器响应数据的难易程度。
结束语
表 1 中的数据并不表明某项序列化技术比其他的技术好。毕竟,六种标准的相对重要性取决于项目的具体情况。例如,如果要处理数百种数据类型,这时想要的是可伸缩性,那么代码生成可能就是最好的选择。
如果需要为同一数据模型生成多个不同视图,那么就应当使用页面模板。如果处理的是小规模项目,想降低需要编写的JavaScript代码数量,那么请考虑JSON。希望这篇文章为您提供了选择适合自己应用程序的序列化技术所需要的的信息
本文作者: