传统 Ajax 与面向新业务的 Ajax 对比

引言

本文将 ASP.NET 所代表的传统 Ajax 与 Visual WebGui 所代表的新 Ajax 方法进行了比较。本文为开发人员提供了一个机会，让他们了解如何使用新的 Ajax 方法来集中开发精力于算法、需求和业务逻辑，该方法能够为任何传统的 Web 应用程序、控件集和架构提供最大的灵活性、互操作性和交互性。

Visual WebGui – 是本文提出的新 Ajax 方法的代表平台。

下载免费试用版

ASP.NET – 在本文中用作比较的基准，尽管也可以选择任何其他传统的 Ajax 开发模式。换句话说，本文将更通用的传统 Ajax 开发方法与 Visual WebGui 的新一代 Ajax 方法进行了比较。

开发人员考虑因素

我们将从以下开发人员角度深入探讨：

1. 开发语言与环境
2. 所需技能
3. 开发工作量和便捷性
4. API 质量和便捷性
5. 使用通用且成熟的设计模式的能力
6. 所需的调试和测试工作量
7. 技术时效性

选择基础设施

此外，我们还将重点介绍在选择用于构建下一条业务线或数据密集型应用程序的平台之前需要考察的一些主要问题。本文将简要讨论以下主题：

1. 基础设施标准
2. 各种数据控件
3. 数据绑定
4. 可扩展性/可定制性与外观
5. 集成/互操作性
6. 性能考虑因素
7. 安全因素
8. 可扩展性

开发人员考虑因素

本节探讨开发人员在选择用于构建下一项目的开发平台时的一些主要考虑因素。

开发语言与环境

您可能会根据现有的技能以及您组织中最普遍的技能来选择开发语言。

Visual WebGui 开发人员可以选择任何 .NET 语言来开发应用程序（例如 C#、VB .NET 等）。Visual WebGui SDK 完全集成到所有 Visual Studio 版本中（图 1）。

Visual WebGui 添加了用户界面，以简化应用程序的配置（图 2）。

不使用 Visual WebGui 而使用 ASP.NET 需要手动进行基于 XML 的配置（图 3）。

所需技能

如果您使用过 ASP.NET 以及任何其他传统的 Web 开发模式，您已经知道任何应用程序开发任务都需要额外的客户端 UI/样式语言和概念：JavaScript 和 DHTML、CSS、Silverlight、Flex/Flash、Java Applets 和 ActiveX 等（图 4 和 5）。

图 4：ASP.NET MVC 应用程序	图 5：Silverlight MVC 应用程序

Visual WebGui 抽象了传统的Web 开发复杂性，并提供了一个单层 .NET 服务器开发平台。

开发工作量和便捷性

纯 ASP.NET 开发为网站开发提供了一个通用的环境，然而，当涉及到应用程序开发，尤其是数据密集型、业务线应用程序时，页面、回发、单个 HttpXml 请求和多层客户端语言的概念迫使您处理更多基础设施问题而非应用程序行为问题。

Visual WebGui 提供您将数据密集型和业务线应用程序的开发体验提升到窗体、事件、对话框、事件驱动的控件间通信和直观面向对象行为的水平。

让我们来看一个简单的任务，例如打开一个数据绑定的模态对话框窗口，这对于业务线 Web 应用程序来说是一项非常常见的任务。

标准 Web 客户端代码

function PopupWindow(url) {
var ie=document.all;
if (ie)
{
        window.showModalDialog(url,”Window”,”status:no; help:no;
                               dialogWidth:1200px; dialogHeight:768px”);
}
else {
      var mywindow =window.open( url, “Popupwindow”,
                             “location=1,status=no,scrollbars=1,width=1200px,
                               height=768px,resizable=1,toolbar=0″ )
                              mywindow.focus();
       }
}

Visual WebGui C# 服务器端代码

LogonForm objLogonForm = new LogonForm(<…params…>);
objLogonForm.ShowDialog();

快速回顾以上代码

• 在 JavaScript 示例中，URL 指向一个完全独立的上下文 URL。
• 为了发送参数到此对话框并处理它们，客户端甚至服务器端还有大量工作要做。
• Visual WebGui 指的是一个完全绑定的对话框，它可以接受任意数量或类型的参数，并可以使用纯面向对象和服务器事件与其他对话框和控件进行交互。
• 从安全角度来看，通过客户端脚本发送参数会自动产生额外的客户端漏洞。

Visual WebGui 使您能够完全控制您的应用程序的逻辑、算法和数据，而无需使用多层 Web 开发语言。所有这些都通过单层面向对象的、事件驱动的代码和窗体设计器（图 6）完成。

图形设计器就绪的工具补充了开发过程，能够轻松提供创意外观和感觉的应用程序（图 7）。

• 无需 CSS 文档（尽管您仍然可以控制它们）
• 无需 HTML 地狱（尽管您仍然可以自定义它们）
• 无跨浏览器不兼容性

下载免费试用版 

需要强调的是，尽管 Visual WebGui 抽象了客户端脚本和资源，但您仍然可以有序地访问这些文件，并且如果需要，您仍然可以覆盖整个脚本、CSS 或 HTML。因此，作为一名 Web 开发人员可以帮助您提供更好的应用程序（图 8）。

API 质量和便捷性

Visual WebGui 提供了一个源自桌面开发 API 的知名 API，但极大地扩展了它以适用于 Web。

ASP.NET 包括第三方组件供应商提供了各种 API，其中大多数都很完善，但另一方面，没有指南或标准让您始终知道如何与这些控件进行接口，并且您永远无法知道是否能够使用常用控件完成未来的任务。

有了 Visual WebGui，您不仅拥有大量功能齐全且具有 AJAX 原生行为的控件，还可以根据您的需求轻松扩展或自定义这些控件。

Visual WebGui API 是事件驱动的；这意味着您的整个开发将集中在处理事件和执行应用程序逻辑上。

例如，让我们探讨一个简单的任务：处理应用程序左侧树节点上的单击事件，并填充右侧的列表。

标准 Ajax 方法

• 找到处理单击树节点时的客户端事件的正确方法。
• 确保您知道如何从选定的树节点读取所需数据。
• 选项 1
  • 使用自由格式的 HttpXml 或 ASP.NET AJAX 将值发送到服务器。
• 选项 2
  • 找到影响列表控件机制的方法，并强制其执行服务器更新调用（带参数）。
• 在服务器端获取值，并检索填充列表所需的任何数据。
• 将数据或内部 HTML 表单发送回客户端。
• 在客户端捕获带有服务器数据的回调。
• 根据需要执行本地列表更新。

Visual WebGui 新 Ajax 方法

• 附加树视图的 AfterSelect 事件。
• 编写事件处理程序代码以检索数据，同时使用纯 C# 将其填充到列表中（如下所示）。

private void treeView1_AfterSelect(object s,TreeViewEventArgs e)
{
   //Populate ListView 
   while (objDataReader.Read())
   {
      for (int i = 0; i < objDataReader.FieldCount; i++)
      {
         ListViewItem objItem = new ListViewItem();
         objItem.Text = objDataReader.GetName(i).ToString();
         objItem.SubItems.Add(objDataReader[i].ToString());
         listView1.Items.Add(objItem);
      }
  }
}

* 整个操作将在服务器上执行一次，
然后在运行时反映回客户端。

快速回顾以上代码

• 开发过程效率低下且冗长，与使用定义明确的事件 API 相反。
• 试想一下，由于树节点单击事件需要更新多个控件；那么您将不得不执行 2 次请求/响应往返。很容易发现 Visual WebGui 在运行时也效率更高，因为它只需一次往返服务器，无需进一步的客户端处理，然后一次返回并在此一次往返中更新整个 UI 更改，并且没有回发。

使用通用且成熟的设计模式的能力

Web 架构几乎完全将客户端和服务器分开，创建了一个解耦的架构，开发人员应该在此架构上找到弥合和覆盖的方法。

在传统的 Web 架构之上，实现定义明确的设计模式通常要复杂得多；例如：

• 数据验证：客户端应该存在哪些类型的验证，服务器上应该测试哪些验证？也许两者都要？
• MVC：我们在哪里实际分割客户端的角色和服务器的角色？此外，如果我们有一些客户端逻辑，这是否意味着我们也应该有一些控制器机制部分在客户端？（图 9、10）

图 9：基于服务器的 MVC	图 10：混合客户端/服务器 MVC

• 观察者/命令：应该向服务器引发哪些类型的事件，以便在侦听器之间冒泡事件？
• 服务定位器：服务定位器代码应该放在哪里？在客户端还是服务器端？也许两者？

一个单层开发环境，您可以在其中使用单一编码语言编写所有代码，并将其视为在复杂的多层环境之上的优化的事件驱动基础设施，这将使您更容易应用质量设计模式。

所需的调试和测试工作量

传统的 Web 调试需要：

• 服务器代码调试（使用 Visual Studio）
• 客户端-服务器通信调试（图 12-13，使用 Visual Studio 和客户端开发工具）
• 客户端脚本语言调试（图 12-14，使用客户端开发工具）
• HTML 和 CSS 的实际渲染（图 14，使用客户端开发工具）

Visual WebGui 调试意味着仅调试面向对象的 C# 代码（图 15）。

技术时效性

假设您已经完成了开发过程，在传统的 Web 开发模式之上创建了精美的应用程序，那么您的客户几乎只能通过 DHTML 浏览器来消费该应用程序。

此外，开发 DHTML 4 和某些 CSS 标准意味着您需要投入大量额外时间来将应用程序升级到更新的标准。

使用 Visual WebGui，您可以在服务器端使用任何 .NET 版本（目前是 2.0 或 3.5），而客户端完全是无关紧要的。Visual WebGui 为任何标准的 DHTML 客户端提供了替代方案，无需安装即可支持任何浏览器，并且支持无需额外开发工作的 Silverlight 增强型浏览器。

Visual WebGui 将继续保持服务器和客户端技术的同步性，让您始终以最小的努力（或零努力）掌握最新的前沿技术（图 16）。

选择基础设施

以下简短说明总结了选择应用程序开发基础设施的主要考虑因素，该基础设施将确保客户满意度和产品质量。

基础设施标准

为了适应大多数客户的当前基础设施，我们应该确保我们的解决方案基于一个知名、现有且经过验证的基础设施。

Visual WebGui 基于 ASP.NET，采用 XCOPY 简单部署。

Visual WebGui 的通信层基于纯 XML（通过 HTTP），支持任何普通 Web 浏览器、Silverlight 或任何设备，无需特定安装！

各种数据控件

为了确保您能够满足任何 UI 需求，以及以任何常见的方式呈现/更新和在应用程序内部（特别是其数据）进行交互，您可能需要检查开箱即用的各种数据控件。

Visual WebGui 包含一套超过 50 个开箱即用的控件，以及一套补充库，包含约 20 个附加控件，为您提供满足任何常见交互和操作需求的完整套件（图 17）。

如果您需要更多，您可以导入任何基于 ASP.NET 的第三方控件、创建自己的控件或自定义现有控件（参见可扩展性/可定制性与外观）。

数据绑定

完整的数据绑定选项使您可以轻松地专注于应用程序的业务逻辑，而不是纠结于各种将 UI 绑定到数据的技术（图 18）。

可扩展性/可定制性与外观

Visual WebGui 的可扩展性和可定制性选项作为面向生产力的工具提供给开发人员。应用设计更改和运行时能力所需的机制被包装在一个优化的引擎中（图 19）。

除了所见即所得的窗体设计器外，Visual WebGui 还提供了一个视觉上简单的解决方案来编辑、重新创建和自定义 Visual WebGui 控件。此外，还可以立即提供一个自动迁移第三方控件的工具，从而立即扩展可用的控件范围，包含任何现有提供商的各种基于 ASP.NET 的控件。

关于品牌和 UI 定制，您拥有完全的权力，可以使用点即点设计器来自定义和品牌化应用程序，以完全按照客户的要求更改外观和感觉。

集成/互操作性

Visual WebGui 基于通用桌面兼容 API，并且得益于其底层基于 ASP.NET 的 Web 特性，它提供了非常广泛的解决方案。从独立应用程序开发、混搭（mash-ups）到高度交互和数据密集型的附加组件。

Visual WebGui 提供 ASP.NET FormBox 控件，该控件能够容纳 ASP.NET 应用程序中的 Visual WebGui 应用程序。图 20 显示了 SAP 的一个大型测试中心应用程序（称为 SNAP），该应用程序结合了 Visual WebGui 和 ASP.NET。中间的数据密集型和交互式部分是 Visual WebGui，而周围的“框架”是 ASP.NET。

反之，Visual WebGui 应用程序也能够包含 ASP.NET 应用程序。此选项以 Visual WebGui 中的 AspPageBox 控件的形式提供（图 21）。

性能考虑因素

尽管 Visual WebGui 是一个以服务器为中心的架构，但它优化了客户端和服务器职责之间的通信和平衡，并提供了低延迟和卓越的性能。重点来说，以下因素产生了这种结果：

• 服务器端 CPU 使用率低，由于始终存在有效上下文，因此建立连接的时间很短。
• 高度优化的通信协议，基于压缩的增量元数据和最小命令。
• 利用客户端机器的强大功能来最小化通信和吞吐量。

协议的有效性在以下图表（图 22-23）中得到体现，这些图表基于性能专家、微软 MVP Wiktor Zychlah 先生进行的外部测试。

 

安全因素

Visual WebGui 的空且静态的客户端，无法更改逻辑，是企业业务应用程序数据安全的理想选择。

并非传统 Web 模式不安全；然而，支持这种信息安全级别所需的努力要大得多。

此外，运行时加密/解密和混淆成本很高，可能会影响性能，因此通过设计避免它们是极力推荐的。

可伸缩性

由于其独特的状态内存和持久化模型（内存序列化）优化，Visual WebGui 应用程序具有完全可伸缩性，采用浮动会话，并且集中式持久状态的平均开销约为每调用 15 毫秒。图 24 显示了示意图。这一事实使 Visual WebGui 成为云计算架构以及本地部署或标准托管部署的优化解决方案。

下载免费试用版