方便 Ajax 与 Java EE 的集成

　　可以看出，由于使用了 Ajax，视图层的脚本编写量增加了，从而导致三个明显缺陷:

• 　　JSP 要求大量的 JavaScript 代码。
• 　　这个设计破坏了角色问题的隔离。
• 　　设计重新带回了单一 JSP(模式 1 方法:一堆 HTML、CSS 代码、图片和脚本代码)，这是一种反模式，极难阅读和维护。

　　有几个选项可以避免或者至少减轻这些设计缺陷:

• 　　设计时脑子里记着重用:不幸的是，编写特定于 Ajax 支持的代码通常很难避免。请计划和设计脚本代码，以便能够最大限度地重用它。
• 　　采用客户端 MVC 方法:可以合并使用客户端 MVC 方法，详见 Dave Crane 等编写的 Ajax in Action。这种方法可以促进问题的隔离，但是增加了复杂性，所以使用的时候要仔细考虑。
• 　　使用 Ajax 框架:存在多个开放源码的 Ajax 框架，例如 Direct Web Remoting (DWR)，它们做了很好的工作，可以用最少的编码，就把 Ajax 模式集成到 Java EE 应用程序。
• 　　重新评估设计的正确性:实际上，Ajax 为 Web 应用程序提供了桌面应用程序的属性。如果一个 Web 应用程序中大多数客户端交互都利用 Ajax，那么这个应用程序可能最好设计成桌面应用程序。

　　处理开发困境

　　在 Java Web 开发中使用 Ajax 时，重要的是完整理解同步 和异步 通信模型的区别。对异步通信模型支持的缺乏，会对客户端开发、与 Web 框架的集成、标记库的使用、IDE 的使用以及线程的行为有影响。

　　在同步请求/响应通信模型中，总是浏览器(与 Web 服务器、应用服务器或 Web 应用程序相对)发起请求(通过 Web 用户)。接着，Web 服务器、应用服务器或 Web 应用程序响应进入的请求。在处理同步请求/响应对期间，用户不能继续使用浏览器。

　　图 2 中的序列图演示了传统 Web 应用程序的同步通信模型。请注意在服务器的生命线上，来自客户机的数据提交和服务器端的处理是紧密耦合的。

　　图 2. 同步通信序列
 

　　在异步请求/响应通信模型中，浏览器(通过 Web 用户)到 Web 服务器、应用服务器或 Web 应用程序的通信(以及反过来)是解耦的。在异步请求/响应对的处理中，Web 用户在当前异步请求被处理时还可以继续使用浏览器。一旦异步请求处理完成，异步响应就被通信(从 Web 服务器、应用服务器或 Web 应用程序)回客户机页面。典型情况下，在这个过程中，调用对 Web 用户没有影响;他们不需要等候响应。

　　图 3 的序列图演示了异步通信模型。请注意第一个 dataSubmission (由服务器端处理)和第一个返回的 dataSubmission，两个都用红圈圈上了。这些序列是解耦的。这个图示还强调了一个重要方面:在这个模型中，可以发生多个提交(线程)。

　　图 3. 异步通信序列

　　客户端影响

　　在向 Web 应用程序引入 Ajax 时，开发团队需要注意几个风险，主要与生成的 HTML 页面及其与浏览器的交互方式有关。这些问题在 Chris Laffra 两部分的 Considering Ajax 系列中有详细介绍。有些需要记住的要点是:

• 　　可能没打开脚本功能:出于各种原因，在许多用户的浏览器上禁止了 JavaScript 支持。
• 　　跨浏览器支持增加了代码需求:支持多种浏览器和多个浏览器版本的应用程序，要求的脚本代码可能会增多，因为浏览器解释 DOM 对象的方式有细微的差异(所以操作这些元素的 JavaScript 代码也有差异)。
• 　　JavaScript 不安全:在多数浏览器中，可以选择查看源代码选项，查看到与 HTML 页面关联的 JavaScript 源代码。在使用 Ajax 模式时，要确保脚本代码中实现的逻辑不是敏感逻辑。

　　与 Web 框架集成

　　试着把 Ajax 开发与所选的 Java EE Web 框架集成，是很自然的。但是有些 Java EE Web 框架对异步通信模型提供直接可以使用的支持。要体会这个事实的意义，需要理解 servlet 处理同步和异步通信的方式。图 4 显示了处理同步请求的传统 servlet 序列: