Visual WebGui 的 Web 开发（WOW）革命
5.00/5 (3投票s)
Visual WebGui 正在重塑 Web 开发，就像 VB6 通过 WOW（Windows Over Web）革命所做的那样。Visual WebGui 实现了类似于 VB 的拖放、面向对象、所见即所得的开发方法，但增加了扩展和定制功能。
通过简化复杂开发席卷全球
仅仅在十五年前，构建一个简单的基于 Windows 的应用程序还可以被称为一场噩梦。这项我们今天习以为常的任务，在 Visual Basic 出现之前，绝非易事。
借助 Visual Basic (VB)，开发人员首次能够通过将控件拖放到窗体上，在直观的图形环境中实现 Windows 应用程序。通过让专业和非专业开发人员都能最大限度地提高生产力，Visual Basic 开启了基于 Windows 应用程序开发的复兴。
Visual Basic 社区在很短的时间内就发展壮大，占据了全球开发人员总数的大部分份额。
它是如何发生的？简单、简单、再简单！Windows 应用程序的简化开发是实现微软基于 Windows 计算愿景的基本组成部分。从这个不起眼的开端，却产生了同样不可思议的结果：它对计算行业产生了深远的影响，永远改变了软件开发的格局，并在 Windows 应用程序市场掀起了一场爆炸式增长。十五年过去了，这似乎显而易见——但当时，只有一小部分精选的开发人员才能够构建 Windows 应用程序，Visual Basic 代表了应用程序设计的一项巨大转变，也是开发社区的一次巨大飞跃。
随后引入了 .NET 语言，以及 Windows Forms 开发范式，开发人员因此获得了更高水平的控制和生产力。通过一流的面向对象构造，如继承、结构化异常处理和参数化构造函数，.NET 编程变得更加优雅、简化和可维护。
Web 和云时代
Web 革命已然到来。Web 迅速成为各种应用程序的首选平台。对 Web 应用程序的需求持续增长，云计算有望带来 Web 需求和使用的又一次飞跃。Ajax 和 RIA 解决方案作为 Web 增强方法，为本身就复杂的 Web 开发增加了更多复杂性。有一些解决方案专注于 Ajax 开发，但没有一个真正带来了像 Visual Basic 那样简化软件行业的革命性影响。Web 和现在的云开发复杂，需要多种语言，掌握多样化的技能，耗时且风险高。这与 Visual Basic 革命之前的桌面开发非常相似。
Visual WebGui WOW 革命
Visual WebGui 将广为人知的 VB6（或 WinForms）开发范式应用于 Web 和云，并增加了明显的更新功能，无需再多赘述。Visual WebGui 实现了类似于 VB6 的拖放、面向对象、所见即所得的开发方法，但增加了扩展和定制功能。它提供了基本的 Windows 外观和感觉，但也支持定制和 Web 2.0 类型的用户界面设计。值得注意的是，微软首席执行官鲍尔默先生在上次的 TechEd Australia 上谈到首选用户界面时说：“用户将期望获得既熟悉又像桌面应用程序一样响应迅速的 Web 界面。人们期望界面的一致性。”
Visual WebGui 将 VB6 开发的简单性扩展到更新的 Web 和云用户界面。它正在改变 Web 开发，就像 Visual Basic 改变桌面开发一样。它的渗透率只能与当年 VB 的渗透率相提并论。自几年前推出以来，Visual WebGui 已被数十万开发人员采用，迄今为止已构建了超过 35,000 个 Visual WebGui 应用程序。
开发人员深入探讨
全新的增强型 VB 式开发体验 vs. 传统 Ajax
引言
以下内容针对传统 Web 开发人员，特别是 ASP.NET 开发人员，他们希望学习一种新的、类似于 VB6 的高效、增强型 Web 开发范式，该范式提供最大的灵活性、互操作性和与任何其他 Web 应用程序、控件集和架构的交互性，从而将他们的开发精力集中在算法、需求和业务逻辑上。
Visual WebGui – 本文档中提出的新 VB 式 WOW 方法的产品。
ASP.NET – 在本文档中被用作比较点，尽管也可以选择任何其他传统 Web 开发范式（JSP、PHP 等）。换句话说，本文档将一种通常被称为当今默认 Web 开发方法的更通用方法与 Visual WebGui 的 WOW 方法进行了比较。
开发人员注意事项
我们将深入探讨以下开发人员视角：
- 开发语言与环境
- 所需技能
- 开发工作量和易用性
- API 质量和便捷性
- 使用常见且成熟设计模式的能力
- 调试和测试所需工作量
- 技术当代性
选择基础设施
此外，我们将重点介绍一些在选择平台来构建您的下一个业务线或数据中心应用程序之前需要检查的主要问题。本文档将简要讨论以下主题：
开发人员注意事项
本节探讨了开发人员在选择开发平台来构建下一个项目时的一些主要考虑因素。
开发语言和环境
您可能会根据您现有的技能以及您组织中最常见的技能来选择开发语言。
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 是事件驱动的；这意味着您的整个开发将集中于处理事件和执行应用程序逻辑。
例如，我们来探讨一个简单的任务，即处理应用程序左侧树节点的点击事件，并填充右侧列表。
标准网页方法
- 找到处理点击树节点客户端事件的正确方法。
- 确保您知道如何从选定的树节点读取所需数据。
- 选项 1
- 使用自由格式的 HttpXml 或 ASP.NET AJAX 将值发送到服务器
- 选项 2
- 找到影响列表控件机制并强制其执行带参数的服务器更新调用的方法
- 在服务器端获取值并检索填充列表所需的任何数据
- 将数据或内部 HTML 表单发送回客户端。
- 在客户端捕获来自服务器的数据回调
- 根据需要执行列表的本地更新
Visual WebGui WOW 方法
- 附加树视图的 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 使用相反。
- 想象一下，如果由于树节点点击事件而需要更新不止一个控件；那么您将不得不执行两次请求/响应往返。很容易发现 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 通信层基于 HTTP 上的纯 XML，支持任何纯 Web 浏览器 Silverlight 或任何无需特定安装的设备！
各种数据控件
为了确保您能够满足任何类型的 UI 需求，并以任何可能的常见方式在应用程序中（更具体地说是其数据）进行呈现/更新和交互，您可能需要检查开箱即用的各种数据控件。
Visual WebGui 包含一套超过 50 个开箱即用的控件，以及一套包含约 20 个附加控件的补充库，为您提供用于任何常见交互和操作的完整套件（图 17）。
如果您需要更多，您可以导入任何基于 ASP.NET 的第三方控件，创建自己的控件，或定制现有控件之一（参见可扩展性/可定制性及外观）。
数据绑定
完整的数据绑定选项使得您可以轻松专注于应用程序的业务逻辑，而不是在各种将 UI 绑定到数据的技术上苦苦挣扎（图 18）。
可扩展性/可定制性及外观
Visual WebGui 的可扩展性和定制选项作为以生产力为导向的工具服务于开发人员。应用设计更改和运行时能力所需的机制被封装在一个优化的引擎中（图 19）。
除了所见即所得的表单设计器之外，Visual WebGui 还提供了一个视觉上简单的解决方案来编辑、重新创建和自定义 Visual WebGui 控件。此外，还启用了一个用于第三方控件迁移的自动工具，立即通过任何现有提供商的各种基于 ASP.NET 的控件来拓宽可用控件的种类。
至于品牌和 UI 定制，您拥有完全的权力，可以使用即点即用设计器根据客户要求完全定制应用程序的外观和感觉。
集成/互操作性
基于通用的桌面兼容 API，并得益于其底层是基于 ASP.NET 的 Web 这一事实，Visual WebGui 提供了一个非常广泛的解决方案。从独立应用程序开发到混搭，再到高度交互和数据中心的附加组件。
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）中，这些图表基于 Microsoft MVP 性能专家 Wiktor Zychlah 先生进行的外部测试。
安全因素
Visual WebGui 空且静态的客户端，无法更改逻辑，是企业业务应用程序数据安全的首选方法。
并非传统 Web 范式不安全；然而，支持此类信息安全级别所需的工作量要大得多。
此外，运行时的加密/解密和混淆成本高昂，可能会影响性能，因此强烈建议在设计时避免它们。
可扩展性
由于状态内存和持久化模型的独特优化（内存序列化），基于 Visual WebGui 的解决方案通过浮动会话实现完全可扩展，集中持久化状态的平均开销约为每次调用 15 毫秒。图 24 显示了示意图。这一事实使得 Visual WebGui 成为云架构以及本地或标准托管部署的优化解决方案。
Windows 到 Web 或云迁移
引言
为了讨论传统桌面应用程序到 Web 的迁移过程，我们应该首先就 3 种不同类型的桌面应用程序达成一致：
- 基于 WinForms 的桌面应用程序（C#/VB.NET）。
UI 层使用 .NET 语言编码 – 业务可以是 .NET、COM+ 或任何其他互操作。 - 基于 VB 6.0 的应用程序。
- UI 层使用 VB 6.0 编码。
- 智能客户端或其他桌面技术（C++ MFC/ATL、Delphi、Java 等）。
任何其他基于智能客户端技术的应用程序。
本文档描述了使用 Visual WebGui 将基于 WinForms 的桌面应用程序迁移到 Web 的过程。
基于 WinForms 的桌面应用程序
背景
通常，如果没有 Visual WebGui，将 WinForms 桌面应用程序迁移到 Web 将需要对 UI 层进行全面重新设计，以适应 Web 架构和功能。
如果我们以 WinForms 迁移到 ASP.NET 为例，使用任何 AJAX 第三方控件来提供丰富的 UI 体验，我们将不得不考虑：
- 全新的 API。
- 全新的更新方法。
- 全新的外观感受——或者努力定制 UI 使其看起来相同。
- 减轻传输到客户端并在任何给定时间呈现的数据量，以避免严重的延迟。
- 由于 Web 限制，功能列表有所妥协。
- 处理因客户端 AJAX 消耗服务和将业务逻辑转移到客户端而产生的安全漏洞。
Visual WebGui SDK 完全集成到 Visual Studio 中，并提供与 WinForms 1.0 和 2.0 开箱即用的完全相同的 API 和工具/功能集。这一事实使得只需将任何现有 WinForms 源代码复制到 VWG 项目中，即可提供功能完全等效的 Web 应用程序。
流程
迁移的基本 3 个步骤
- 打开新的 Visual WebGui 应用程序。
- 将代码从 WinForms 项目复制到这个新的 Web 应用程序中。
- 将代码中所有对 WinForms API 命名空间（“System.Windows.Forms”）的引用替换为 Visual WebGui API 引用（“Gizmox.WebGUI.Forms”）。
任何使用 58 个 WinForms 开箱即用控件的标准 WinForms 应用程序都将编译并作为纯 Web 应用程序执行。
这个简短过程的结果是一个基于 ASP.NET 的解决方案，就部署和运行时而言，它具有以下特性：
- 部署与 ASP.NET 网站等同于复制粘贴。
- 服务器基础设施仅需要 IIS 和 .NET CLR。
- 应用程序可以从任何普通浏览器使用——客户端无需安装。
- 由于空客户端概念，客户端上只有少量静态和缓存的足迹，大约 200kb 的纯 JS 和 HTML 代码。
- 支持使用相同代码库的多个表示层（DHTML/Silverlight 或智能客户端）
- 维护单层代码 – 无需编写或维护 JavaScript、HTML 和服务
- 由于空客户端概念，高度安全。
注意事项和例外
在迁移过程中可能会遇到 3 个主要障碍，您可以提前量化这些障碍，并估算完成应用程序迁移所需的工作量：
- VWG API 和 WinForms 之间细微的差异，主要由架构差异引起。
- 应用程序中使用的第三方控件的数量。
本节描述了使用一些非 WinForms 开箱即用控件（例如 Infragistics 或 DevExpress 控件等）的情况。在这些情况下，您可以从以下 3 个选项中选择最合适的解决方案：
- 从 WinForms 开箱即用控件中选择一个类似的控件，调整您的代码以使用它，然后执行迁移过程。
- 选择一个等效的第三方 ASP.NET 控件（Infragistics、Telerik、DevExpress 等），它提供相同的功能，在 VWG 中一键封装，并调整您的代码以使用它。
- 编写您自己的 VWG 自定义控件，它将完全满足您的需求，然后在迁移过程之后调整您的代码以使用此控件。
- 将单用户桌面应用程序调整为多用户 Web 环境。本节总结了将单用户应用程序转换为共享相同 CPU、内存空间和其他资源的多用户应用程序的一些主要问题。
- 线程安全 – 由于 WinForms 应用程序可能包含可供单个用户访问的静态成员，您现在应该考虑以下选项之一：
- 将这些静态成员替换为同步的多线程安全数据结构。
- 锁定关键的读/写部分以保护并发的多用户访问。
- 删除静态成员并寻找基于实例或数据库的解决方案。
- 内存负载 – 在桌面应用程序中，有时会根据执行机器是本地的假设来考虑使用的内存量。因此，许多项目同时加载到内存中而不受限制。
现在，在共享内存环境中，当服务器执行繁重工作时，每个用户消耗的内存量将决定每个服务器可以服务的并发用户数量。
建议采取以下步骤：
- 考虑按需加载项目到内存（只在内存中保留标题和标识符）。
- 删除加载到内存中的任何大型对象——例如，不要将二进制对象保存到内存中，而是将二进制文件直接写入响应流到客户端。
- 优先使用基于数据库的分页，而不是完整的前缀和基于内存的分页。Visual WebGui 提供机制来轻松实现这一点。
- 线程安全 – 由于 WinForms 应用程序可能包含可供单个用户访问的静态成员，您现在应该考虑以下选项之一：
摘要
使用 Visual WebGui 将任何 WinForms 应用程序迁移到 Web 具有以下优势：
- 通过 3 个简单的步骤，您将能够非常接近一个可运行的 Web 应用程序。
- 您为实现功能齐全的 Web 应用程序所需付出的努力是可衡量的。
- 应用程序可以继续使用现有的 BL 和 DL 层，只有 UI 是自动迁移或调整的。