方便ajax与javaee的集成s8vody61.doc

方便Ajax与JavaEE的集成 随着 Ajax 的兴起，对于消解这个热门技术的谜团并有针对性地处理在它的使用中出现的问题的需求出现了。高级 IT 专家 Patrick Gan 利用这个机会，研究了在 Java? EE Web 应用程序中引入 Ajax 对整个开发生命周期可能产生的影响。对采纳 Ajax 基于异步通信的模式会存在的问题保持清醒，有助于踏上有效集成 Ajax 的正确道路。 Asynchronous JavaScript + XML （Ajax）是个相当新的术语（有些人说它是旧酒装新瓶），在不同的 Web 开发社区中，都引起了很大的争议，其中包括 Java EE 社区。Ajax 技术通过消除过多的 Web 页面刷新，提高了应用程序的可用性。而且 Ajax 二者通吃的技术，同时利用了客户端和服务器端代码，向 Web 用户呈现了几乎无缝的用户界面。Ajax 被鼓吹成 Web 开发复兴（或称为 Web 2.0）的一个主要推动者。 作为用心的 Java EE 开发人员，您可能已经阅读了许多关于 Ajax 的 how-to 文章，并对它会给应用程序带来的可能改进而兴奋。但是 Ajax 基于异步通信的模式要怎样才适合您的 Java EE 应用程序呢？这篇文章通过研究在 Java EE 应用程序的设计、开发、执行和测试各阶段引入 Ajax 会带来的影响，将帮助您回答这个问题。我的目的不是不鼓励使用 Ajax 或者暗示您可能遇到的问题是 Ajax 技术固有的问题。相反，我是为了帮助您规划并减轻这些问题，好让您更有效而顺利地利用 Ajax。 解决设计缺陷 相当一段时间以来，Java 社区一直在努力把好的设计模式应用到与 Web 有关的应用程序开发上。其中使用最广泛的一个模式就是模型-视图-控制器（MVC）。一些开放源码框架，例如 Apache Struts，就基于这个设计模式/架构（请参阅）。MVC 的众多优势包括：问题隔离和减少冗余代码。 问题隔离在整个应用程序架构中使用预先协商好的接口，从而让应用程序开发项目中的每个开发人员都专注于自己特定的角色。例如，模型层的开发人员侧重于 JDBC、企业 JavaBean（EJB）组件或者与底层数据持久技术接口的 Java 类这一类的技术。视图层开发人员侧重于 Java 服务器页面（JSP）技术、标记库和其他与表示有关的技术。控制器层隔离及协调模型和视图，把进入的请求路由到后端持久性调用，同时维护问题的清晰隔离。图 1 演示了 MVC 架构： 图 1. MVC 架构 表 1. 没有 Ajax 的 MVC：与典型的视图层序列有关的代码数量 序列 说明 要求代码？ 在调用同步请求之前 准备表单提交需要的脚本代码 否 调用异步请求 由按钮或链接调用引起表单提交；DOM 元素的值自动设置到HttpRequest（通过GET或POST）。 否：所需要的只是调用页面提交的途径。 处理同步请求的响应 在服务器端代码执行完成后，通常会向 JSP 发送回一个对象（通过HttpRequest或保存在HttpSession中）。这时，在 JSP 中可以通过HttpRequest或HttpSession访问这个对象（通过脚本或某些标记库），只需要编写极少的脚本就可以显示对象的内容。 是：最少的脚本。 对比表 1 和表 2，表 2 描述了有Ajax 的 MVC 视图层，同样假设控制层由 servlet 实现，视图层由 JSP 技术实现。 表 2. 有 Ajax 的 MVC：与典型的视图层序列有关的代码数量 序列 说明 需要代码？ 在调用异步请求之前 需要用 JavaScript 代码检索出 Ajax 调用需要的 DOM 元素的值。 是 调用异步请求 需要用 JavaScript 代码创建XMLHTTPRequest并把（以前搜集的）DOM 元素值与之关联并发送（XMLHTTPRequest.send()）。 是 处理异步请求的响应 在服务器端代码执行完成后，要用 JavaScript 代码得到请求（从 XML 响应流中）并把值相应地填充到适当的 DOM 元素。 是 可以看出，由于使用了 Ajax，视图层的脚本编写量增加了，从而导致三个明显缺陷： 1. JSP 要求大量的 JavaScript 代码。 2. 这个设计破坏了角色问题的隔离。 3. 设计重新带回了单一 JSP（模式 1 方法：一堆 HTML、CSS 代码、图片和脚本代码），这是一种反模式，极难阅读和维护（请参阅）。 有几个选项可以避免或者至少减轻这些设计缺陷： 1. 设计时脑子里记着重用：不幸的是，编写特定于 Ajax 支持的代码通常很难避免。请计划和设计脚本代码，以便能够最大限度地重用它。