AJAX 应用程序体系结构(第2部分)(1)

使用 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);
}