AJAX 应用程序体系结构

使用 ASP.NET AJAX Extensions 将您的站点过渡到 AJAX 体验时，有两个主要的编程模型可供选择：部分呈现和脚本服务。在上个月的专栏中，我主要从体系结构的角度论述了部分呈现。简而言之，使用部分呈现，您无需更改 ASP.NET 应用程序的底层体系结构——它是实现 AJAX 某些最佳元素（如站点页面的无闪烁更新）的便捷途径。实现此类改进行为只需添加一些新的服务器控件（特别是 ScriptManager 和 UpdatePanel），并让它们悄悄地施展一些技巧，通过 XMLHttpRequest 对象运行的异步请求来转换传统的回在发。此方法很容易实现，因为它只是将 AJAX 功能应用于现有的 Web 开发模型。

如果您准备对构建 AJAX 应用程序实行全面的模式转换，那么就应该了解一下脚本服务的方法。总的来说，典型的 AJAX 体系结构相当容易理解。图 1 展示了其工作原理的高层视图。其中有一个由应用程序特定服务组成的后端，通常只是可调用 AJAX 脚本的外层，其下方是业务逻辑所在和发挥作用的系统中间层。服务与前端通过 HTTP 交换数据，使用多种格式传递参数和返回值。前端由运行于客户端上的 JavaScript 代码组成，在接收和处理完数据后，它面临着使用 HTML 和 JavaScript 构建图形用户界面的重大任务。对 JavaScript 的依赖是由于受浏览器结构的限制，只有当浏览器可以支持功能更加强大的编程功能时，这种情况才会改变。

图 典型的 AJAX 体系结构

 
通过 AJAX 登录

抛弃传统的 ASP.NET 模型会引起许多实际反响。考虑一下登录过程，看看在纯 AJAX 解决方案中会发生怎样的变化。

当前对 ASP.NET 来说，启用登录过程包括：用 Login 控件配置登录页面，用 LoginView 控件配置受保护的页面，设置 ASP.NET 成员身份提供程序。受保护的页面将使用登录模板或匿名模板以图形方式反映身份验证过程的结果。在 ASP.NET 2.0 中，您无需编写任何代码即可完成大部分此类工作。要成功地进行登录，需要有用户到达受保护页面时发生的重定向 (HTTP 302)、从登录页面到身份验证凭据的回发，然后是回到原先请求页面的另一次重定向。

对于 AJAX 页面来说则并不一定如此。如果用户从地址栏请求一个受保护的页面，除了重复 ASP.NET 的历程之外，您并不能做什么。不过，如果您在页面中有指向受保护页面的链接，则可以将某些脚本添加到该链接的 onclick 事件上，以检查用户是否已通过身份验证。如果没有，则可以弹出一个警告框以提醒用户，如下所示：
 

				
function checkFirst()
{
    var loggedIn = Sys.Services.AuthenticationService.get_isLoggedIn();
    if (!loggedIn)
    {
        alert("You must be logged in to follow this link");
        return false;
    }
    return true;
}
		

如您所见，除了其他方面之外，此方法使用一个客户端框架来帮助您检查当前用户是否已登录。凭借 ASP.NET AJAX Extensions 即可通过 Sys.Services.AuthenticationService 类实现该功能。

同样的服务可用于在用户指定有效凭据后对其进行身份验证。在这种情况下，不发生任何重定向和回发。一切都发生在同一页面的环境中，如下面的代码段所示：

				
function OnLogin()
{
   Sys.Services.AuthenticationService.login(
      $get("UserName").value,
      $get("Password").value,
      false,
      null,
      null,
      OnLoginCompleted,
      OnLoginFailed);
}
		

检查凭据成为使用脚本服务进行身份验证的标准脚本操作。这完全要靠开发人员来更新客户端页面的 UI，以反映身份验证成功后用户已处于登录状态。除非您使用的框架提供了一个将 HTML 包装在控件中的对象模型，否则，编写文档对象模型 (DOM) 脚本的过程要长得多。注意，ASP.NET AJAX Extensions 目前尚不提供用控件代表标记块的对象模型。

服务的风格

在 AJAX 中，服务表示驻留在应用程序域并向客户端脚本代码公开功能的一段代码。AJAX 中使用的服务需要进行某种设计，以便实现对实际应用程序后端和中间层的保护，避免其与最终用户直接交互。此类服务是 WS-* Web 服务吗？它可以是面向服务的体系结构 (SOA) 服务吗？

最适合 AJAX 应用程序的服务主要涉及向 Web 客户端公开数据和资源。它可以通过 HTTP 获得，并要求客户端使用 URL（也可以是 HTTP 头）访问数据和命令操作。客户端与服务进行交互使用的是 HTTP 动词，如 GET、POST、PUT 和 DELETE。换句话说，URL 代表一个资源，而 HTTP 动词描述了您想对资源采取的操作。在这些交互中交换的数据以简单格式表示，如 JSON 和纯 XML，也可以整合格式表示，如 RSS 和 ATOM。

具有这些特征的服务是 Representational State Transfer (REST) 服务。有关 REST 定义的详细信息，请阅读描述 REST 前景的原作（在 ics.uci.edu/~fielding/pubs/dissertation/top.htm 中提供）。

最后，AJAX 应用程序所使用的服务并不倾向于使用 SOAP 进行通信，而且不一定是 SOA 意义上的自治服务。相反，它们与承载自身的平台和域相绑定。基于这一点，它们几乎不能称为 WS-* Web 服务或 SOA 服务。

此外，这些服务是不使用公共文档资料或发现架构的范例，这一点与 WS-* Web 服务的 Web 服务描述语言 (WSDL) 这类事物不同。这会减少依附于服务的依赖关系的数量，并使服务代码更加迅速地演变。总而言之，为 AJAX 服务推荐的模式不像 Web 和 SOA 服务背后的模式那样雄心勃勃，但对于将要使用它的环境来说，它依然十分有效。

注意，在本专栏的其余部分，我将使用“AJAX 服务”的说法表示通过脚本服务方法实现 AJAX 应用程序后端的服务。

AJAX 服务返回什么？

既然公开 AJAX 服务的唯一方式是通过 HTTP，那么就几乎可以使用任何文本格式来包装请求和响应的主体。JavaScript Object Notation (JSON) 是最常用的格式，但也可使用其他格式，如纯 XML 和原始文本。

JSON 是基于文本的格式，用于跨应用程序的各层移动对象的状态。JSON 字符串通过常见的 eval 函数便可方便地赋给 JavaScript 对象。JSON 格式描述了对象，如下所示：
{"ID":"ALFKI", "Company":"Alfred Futterkiste"}

该字符串表示一个对象有两个属性，即 ID 和 Company，以及它们各自的文本序列化值。如果对某个属性赋予非基本类型的值（比如自定义对象），那么该值将递归地序列化为 JSON，如下所示：

 "ID":"ALFKI", 
 "Company":"Alfreds Futterkiste",
 "Location":
      "{"City":"Berlin", "Country":"Germany"}",
}

使用 eval 函数进行处理时，JSON 字符串将变成一个关联性数组（即一种名称/值的集合），其中每个条目都有一个名称和值。如果 JSON 字符串用于代表一个自定义对象（比如 Customer）的状态，那么，您必须负责确保客户端具有相应类的定义。换句话说，JavaScript 的 eval 函数只是将 JSON 字符串中的信息提取到一个通用容器。如果您需要将此信息公开为一个自定义对象（比如 Customer 对象），那么提供类定义并将数据载入到其中的任务就完全依靠您或您使用的框架来完成。有关 JSON 语法和用途的更多信息，