35、Web数据库应用的可扩展性与数据录入解决方案

Web数据库应用的可扩展性与数据录入解决方案

在Web应用开发中,随着用户数量的增加和业务需求的不断变化,系统的可扩展性和数据录入的便捷性成为了关键问题。本文将介绍一些提升Web应用可扩展性的策略,以及Web数据录入的多种解决方案。

提升Web应用可扩展性的策略
1. 在Web服务器上添加实例

在Web服务器上运行Visual FoxPro应用程序的额外实例,可以并行处理多个Web请求。这在多处理器机器上尤为有效,但在以下两种情况下也有帮助:
- 若某些请求处理时间较长,运行多个实例可让部分用户获得更快响应,无需等待长时间运行的请求完成。
- 若数据存储在不同的后端服务器上,应用程序在处理查询时可能会有显著的等待时间,此时在单处理器机器上运行多个实例也能有所帮助。

添加实例可通过COM或基于文件的消息传递实现:
- 使用COM :只需在WC.INI文件中为每个要运行的额外实例添加一行。
- 使用基于文件的消息传递 :直接启动Visual FoxPro可执行文件的额外实例。一般经验法则是每个处理器运行两个实例,但最佳数量需通过严格的压力测试确定。当系统发生重大变化(如添加处理器、内存或驱动器)时,应重新评估该数量。

此外,COM本身的性能优于基于文件的消息传递,有时将消息传递机制切换为COM可显著提高系统吞吐量。

2. 利用额外网络机器分担负载

当Web服务器的处理能力达到极限时,可以让网络中的其他机器分担负载。虽然使用COM或基于文件的消息传递都可行,但基于文件的消息传递在设置和管理方面更具优势。

使用基于文件的消息传递分担负载的步骤
1. 在一个或多个额外的网络机器(可以是服务器或工作站)上启动应用程序的副本。
2. 所有机器通过检查Web服务器上的一个公共临时目录来查找新请求。为确保所有参与机器使用相同目录,可在INI文件中使用UNC设置或采用通用的网络驱动器映射策略(如始终将驱动器W:映射到Web服务器,然后指向W:驱动器上的临时文件夹)。
3. 确保数据路径设置为所有参与机器都可访问的值,并设置权限,使每台机器都能访问运行应用程序所需的所有资源。

使用COM进行负载分担需要复杂的设置和管理,不建议普通开发者使用,除非你有扎实的Windows网络背景。

3. 将数据迁移到不同后端

将数据迁移到单独机器上的不同后端(如Microsoft SQL Server),可减轻Web服务器的处理负载。在某些情况下,这一操作本身就能提高系统吞吐量。同时,由于数据处理活动被卸载到不同后端,每个实例的活动水平降低,可增加Web服务器上应用程序实例的数量。

4. 扩展到Web农场

Microsoft Windows 2000 Advanced Server包含网络负载均衡(NLB)服务。使用此服务可实现Web农场,以达到更高的可扩展性。要使用此策略,需要两台或更多使用Windows 2000 Advanced Server的Web服务器,且所有数据(包括会话和日志文件)必须存储在单独的后端机器上。详细信息可参考West Wind Technologies网站上的白皮书:www.west - wind.com/presentations/LoadBalancing/LoadBalancing.htm

5. 进一步物理分层

还可通过将系统进一步划分为更多物理层来提高可扩展性。例如:
- 创建一个单独的数据访问层,以COM + 包的形式在单独的服务器上运行。
- 将特殊的、资源密集型的进程拆分为可在其他机器上运行的组件,如信用卡验证、电子邮件服务以及维护和会计任务。

在实施任何可扩展性策略之前,务必充分了解整个系统以及要解决的“问题”。如果系统吞吐量不足,在花费时间和金钱进行更改之前,要确定Visual FoxPro应用程序是否真的是问题所在,因为问题可能出在网络或电信瓶颈等其他方面。

以下是提升Web应用可扩展性策略的总结表格:
| 策略 | 优点 | 缺点 | 适用场景 |
| — | — | — | — |
| 在Web服务器上添加实例 | 提高并行处理能力,在多处理器机器上效果好 | 需要确定最佳实例数量,可能增加系统复杂性 | 部分请求处理时间长或数据在不同后端服务器的情况 |
| 利用额外网络机器分担负载 | 可利用网络中其他机器的资源,基于文件的消息传递设置和管理相对简单 | 使用COM设置和管理复杂 | Web服务器处理能力达到极限时 |
| 将数据迁移到不同后端 | 减轻Web服务器处理负载,可增加实例数量 | 需要配置不同后端服务器 | 系统吞吐量受数据处理影响较大的情况 |
| 扩展到Web农场 | 实现更高的可扩展性 | 需要多台Web服务器和单独的后端机器 | 对系统可扩展性要求极高的情况 |
| 进一步物理分层 | 提高系统的灵活性和可扩展性 | 增加系统架构的复杂性 | 有特殊资源密集型进程或需要精细分层的情况 |

Web数据录入的挑战与解决方案

在仅存在于Web上的应用程序中,所有数据录入都必须通过基于Web的表单进行。与Windows应用程序使用Visual FoxPro表单设计器不同,设计基于Web的表单的最佳方法并不明显。

数据录入困难的原因

以更新单个字段为例,对比Windows应用程序和手工编码的Web应用程序:
- Windows应用程序 :使用表单或类设计器,将文本框控件拖放到表单上,然后将控件绑定到数据源(视图或业务对象属性)。用户输入值时,Visual FoxPro会自动将该值存储到相应的控件源,开发者无需过多操作。
- 手工编码的Web应用程序 :即使有管理数据访问的框架,仍需完成以下任务:
1. 为每个控件创建HTML表单元素名称。
2. 将表单元素以HTML形式呈现给浏览器,并确保显示当前数据值。
3. 编写代码从POST缓冲区读取用户提交的值。
4. 将所有提交的值转换回原生数据类型,并处理无效值。
5. 如果提交有效,将提交的值保存到正确的控件源。
6. 如果提交无效,需要有相应策略,如显示错误消息和/或重新呈现表单以供修正。

以下是一个简单的示例代码,展示了手工编码的Web应用程序中编辑单个文本字段的情况:

* 渲染部分
LOCAL lcStr
lcStr = [<tr><th>Customer Name:</th>] + CRLF
lcStr = m.lcStr + [<td><input name="txtCustomer_Name" type="text" value="] + ;
  TRIM( V_Customer.Customer_Name) + [" size=50>] + [</td></tr>] + CRLF
Response.Write( m.lcStr)

* 表单处理部分
LOCAL lcCustomer_Name
lcCustomer_Name = Request.Form( "txtCustomer_Name")
IF (some validation check)
  REPLACE V_Customer.Customer_Name WITH m.lcCustomer_Name
ELSE
  THIS.ErrorMsg( "Invalid reponse.")
ENDIF

可以看到,代码中“Customer_Name”出现了多次,且一个字段的代码就已经较为复杂。如果表单有多个字段,或者应用程序有多个数据录入表单,维护将成为噩梦。此外,Web表单还存在错误不易察觉的风险,例如在传递给Request.Form()的参数中遗漏下划线,不会产生任何错误,但用户的更改将无法保存。

设计替代方案

有多种解决方案可供选择,包括:
- 手工编码所有表单 :具有较高的灵活性,但维护成本高。
- 手工编码表单处理,使用Web Connection脚本进行可视化布局 :结合了手工编码和可视化工具的优点,但仍存在维护问题,且需要协调代码和脚本文件的更改。
- 使用wwShowCursor类 :该类的EditTable()方法可快速生成HTML数据录入表单并绑定到本地Visual FoxPro数据,但仅适用于管理功能,如更新系统表,不支持字段验证和缓冲视图或业务对象。
- 使用wwForm和wwCtls类通过DHTML呈现Visual FoxPro表单 :可将某些Visual FoxPro表单在Web上呈现,适合习惯现有网络应用程序表单外观的用户。但性能可能较差,生成的DHTML仅与Microsoft Internet Explorer兼容,并非所有控件都能呈现为DHTML。
- 使用第三方工具,如EPS Software的Voodoo Web Controls :设计时考虑了数据绑定,可绑定到视图、业务对象或XML。提供了直观的属性和方法来,可轻松集成JavaScript,指定自己的事件代码,并指定浏览器上的哪些事件会导致往返服务器。
- 创建自己的类库 :可根据具体需求定制,但开发成本较高。
- 尝试将类库(第三方或自己的)与可视化表单布局工具(如Microsoft FrontPage)结合使用 :结合了类库的功能和可视化工具的便捷性,但可能存在兼容性问题。

在选择解决方案时,可考虑以下属性:
| 属性 | 描述 |
| — | — |
| 可维护性 | 表单创建后维护的效率和易出错程度 |
| 灵活性 | 实现单个表单特定需求的灵活程度,如更改布局、选择性禁用和移除表单元素 |
| 复杂表单支持 | 是否易于创建复杂表单,如带有页面框架和网格状控件的表单 |
| 浏览器兼容性 | 生成的输出能否被主流浏览器访问 |
| 可视化布局能力 | 是否允许使用可视化工具(如Macromedia Dreamweaver、Adobe GoLive或Microsoft FrontPage)进行表单布局 |
| 外观控制 | 开发者能否在具有多个数据录入表单的应用程序中创建和维护一致的外观,是否支持应用程序范围的级联样式表(CSS) |
| 可访问性选项 | 是否能适应W3C可访问性指南中某些用户的需求,如关联标签与控件、避免使用固定字体大小等 |
| 客户端验证 | 是否支持包含客户端JavaScript以减轻服务器验证负担并改善用户体验 |
| 服务器端验证 | 对表单提交的服务器端验证支持程度 |
| 数据绑定 | 支持表单控件与数据元素绑定的效果,是否支持开发者偏好的方法,如本地/远程视图、SQL传递和业务对象 |
| 开发者效率 | 开发者创建新数据录入表单的速度 |
| 性能 | 使用该方法的Web应用程序的性能 |
| 成本 | 是否需要除Web Connection之外的额外支出 |
| 解决方案的可用性 | 实现该解决方案的技术是否可用 |

以下是一个简单的mermaid流程图,展示了选择Web数据录入解决方案的过程:

graph TD;
    A[开始] --> B[评估需求];
    B --> C{是否需要高灵活性};
    C -- 是 --> D[考虑手工编码表单];
    C -- 否 --> E{是否注重可视化布局};
    E -- 是 --> F[考虑使用脚本或可视化工具结合类库];
    E -- 否 --> G{是否需要强大的数据绑定和验证功能};
    G -- 是 --> H[考虑Voodoo Web Controls];
    G -- 否 --> I[考虑wwShowCursor类或自己创建类库];
    D --> J[评估维护成本];
    F --> J;
    H --> J;
    I --> J;
    J --> K{维护成本是否可接受};
    K -- 是 --> L[选择该解决方案];
    K -- 否 --> B;
    L --> M[结束];

综上所述,在Web应用开发中,可扩展性和数据录入是需要重点关注的方面。通过合理选择提升可扩展性的策略和Web数据录入的解决方案,可提高系统的性能和开发效率,满足不同用户的需求。

Web数据库应用的可扩展性与数据录入解决方案

各数据录入解决方案的评估

接下来,我们将根据前面提到的各项属性,对不同的数据录入解决方案进行评估。

手工编码表单
  • 可维护性 :维护成本较高,随着表单字段和表单数量的增加,代码重复度高,容易出错。例如,一个包含25个字段的表单,字段名在代码中多次出现,修改时容易遗漏。
  • 灵活性 :具有很高的灵活性,可以根据具体需求轻松地插入条件语句来修改表单,如为不同用户角色显示或隐藏特定字段。
  • 复杂表单支持 :对于简单表单可以较好实现,但创建复杂表单(如带有页面框架和网格状控件)时,代码编写和维护难度大。
  • 浏览器兼容性 :由于是纯HTML代码,只要遵循标准,可被主流浏览器访问。
  • 可视化布局能力 :不支持使用可视化工具进行布局,需要手动编写HTML和CSS代码。
  • 外观控制 :开发者需要手动编写CSS来控制外观,难以在多个表单中保持一致的样式。
  • 可访问性选项 :需要开发者手动遵循W3C可访问性指南,如关联标签与控件、避免使用固定字体大小等。
  • 客户端验证 :需要手动编写JavaScript代码来实现客户端验证。
  • 服务器端验证 :同样需要手动编写代码进行服务器端验证。
  • 数据绑定 :需要手动编写代码将表单控件与数据元素绑定,过程繁琐。
  • 开发者效率 :创建新表单的速度较慢,尤其是对于复杂表单。
  • 性能 :由于代码简洁,没有额外的框架开销,性能较好。
  • 成本 :除了开发时间成本,无需额外支出。
  • 解决方案的可用性 :只要掌握HTML、CSS和JavaScript知识即可实现。
手工编码加脚本
  • 可维护性 :虽然使用可视化工具进行布局可以减少一些手工编码的工作量,但仍需要协调代码和脚本文件的更改,维护难度较大。
  • 灵活性 :在一定程度上结合了手工编码的灵活性和可视化工具的便捷性,但由于涉及代码和脚本的交互,灵活性有所降低。
  • 复杂表单支持 :比纯手工编码更适合创建复杂表单,但仍有一定难度。
  • 浏览器兼容性 :取决于可视化工具生成的代码,一般可被主流浏览器访问。
  • 可视化布局能力 :可以使用可视化HTML编辑工具进行表单布局,提高了开发效率。
  • 外观控制 :如果可视化工具支持CSS管理,可在一定程度上实现一致的外观。
  • 可访问性选项 :需要开发者在代码和脚本中考虑可访问性问题。
  • 客户端验证 :需要手动编写JavaScript代码,结合可视化工具的事件处理机制。
  • 服务器端验证 :手动编写服务器端验证代码。
  • 数据绑定 :手动编写代码实现数据绑定。
  • 开发者效率 :比纯手工编码快,但仍需要一定的时间来协调代码和脚本。
  • 性能 :由于增加了脚本处理,性能可能略有下降。
  • 成本 :除开发时间成本外,可能需要购买可视化工具。
  • 解决方案的可用性 :需要掌握可视化工具和相关脚本语言。
使用wwShowCursor类
  • 可维护性 :由于代码量少,对于简单的管理功能表单,维护相对容易。但对于复杂需求,不适用,可维护性降低。
  • 灵活性 :灵活性较差,只能满足基本的管理功能,如更新系统表,无法实现复杂的表单需求。
  • 复杂表单支持 :不支持创建复杂表单,只能实现一行一个字段的简单布局。
  • 浏览器兼容性 :生成的HTML代码可被主流浏览器访问。
  • 可视化布局能力 :不支持使用可视化工具进行布局。
  • 外观控制 :难以控制表单的外观,缺乏样式定制能力。
  • 可访问性选项 :需要开发者手动添加可访问性支持。
  • 客户端验证 :不支持字段验证。
  • 服务器端验证 :不支持字段验证。
  • 数据绑定 :只能绑定到本地Visual FoxPro数据,且功能有限。
  • 开发者效率 :对于简单表单,开发速度快。
  • 性能 :由于功能简单,性能较好。
  • 成本 :无需额外支出。
  • 解决方案的可用性 :Web Connection自带,易于使用。
使用wwForm和wwCtls类通过DHTML呈现Visual FoxPro表单
  • 可维护性 :如果SCX文件代码较少,可维护性较好。但由于需要在服务器上为每个Web请求实例化和运行代理表单,代码复杂度增加,维护难度也相应提高。
  • 灵活性 :可以利用现有的Visual FoxPro表单,但由于部分功能限制,灵活性不如手工编码。
  • 复杂表单支持 :对于部分Visual FoxPro表单可以较好呈现,但不是所有控件都能渲染为DHTML,复杂表单的支持有限。
  • 浏览器兼容性 :生成的DHTML仅与Microsoft Internet Explorer兼容,限制了用户群体。
  • 可视化布局能力 :可以利用Visual FoxPro的表单设计器进行布局。
  • 外观控制 :可以在一定程度上继承Visual FoxPro表单的外观,但由于浏览器兼容性问题,难以实现一致的外观。
  • 可访问性选项 :需要开发者手动添加可访问性支持。
  • 客户端验证 :由于部分事件不支持,客户端验证实现较困难。
  • 服务器端验证 :可以在服务器端运行表单时进行验证。
  • 数据绑定 :可以绑定到Visual FoxPro的数据对象,但性能可能受影响。
  • 开发者效率 :对于已有Visual FoxPro表单的迁移,开发速度较快。
  • 性能 :由于需要在服务器上运行表单,性能较差。
  • 成本 :无需额外支出。
  • 解决方案的可用性 :Web Connection自带,但受浏览器兼容性限制。
使用Voodoo Web Controls
  • 可维护性 :代码具有Visual FoxPro的风格,对于熟悉Visual FoxPro的开发者来说,维护相对容易。数据绑定和验证逻辑集中管理,减少了代码重复。
  • 灵活性 :设计时考虑了数据绑定和验证,可通过属性和方法灵活控制表单的行为,如指定事件代码和往返服务器的条件。
  • 复杂表单支持 :可以较好地支持复杂表单的创建,如带有多个控件和验证逻辑的表单。
  • 浏览器兼容性 :可通过合理设计和测试,实现与主流浏览器的兼容。
  • 可视化布局能力 :可以结合可视化工具进行布局,但主要侧重于代码实现。
  • 外观控制 :可以通过CSS和属性设置控制表单的外观,实现一致的样式。
  • 可访问性选项 :可以通过代码实现W3C可访问性指南的要求。
  • 客户端验证 :提供了直观的属性和方法来集成JavaScript,实现客户端验证。
  • 服务器端验证 :在表单提交时可进行服务器端验证,确保数据的完整性。
  • 数据绑定 :支持绑定到视图、业务对象或XML,提供了多种数据绑定策略。
  • 开发者效率 :由于提供了现成的控件和方法,开发速度较快。
  • 性能 :性能较好,尤其是在数据绑定和验证方面。
  • 成本 :需要购买基础包,一个开发者的基础包许可证费用为299美元。
  • 解决方案的可用性 :需要Visual FoxPro 7或更高版本,且需要掌握相关的使用方法。
创建自己的类库
  • 可维护性 :可根据具体需求定制类库,维护性取决于类库的设计质量。如果设计合理,可提高代码的复用性和可维护性。
  • 灵活性 :具有最高的灵活性,可以根据业务需求完全定制类库的功能。
  • 复杂表单支持 :可以根据需要实现对复杂表单的支持。
  • 浏览器兼容性 :需要开发者手动确保生成的代码与主流浏览器兼容。
  • 可视化布局能力 :可以结合可视化工具进行开发,但需要自己实现与类库的集成。
  • 外观控制 :可以通过自定义CSS和样式类来控制表单的外观。
  • 可访问性选项 :可以在类库中实现可访问性支持。
  • 客户端验证 :需要在类库中实现客户端验证逻辑。
  • 服务器端验证 :需要在类库中实现服务器端验证逻辑。
  • 数据绑定 :可以根据需求实现各种数据绑定策略。
  • 开发者效率 :开发成本高,开发新表单的速度较慢,尤其是在类库开发初期。
  • 性能 :性能取决于类库的实现质量。
  • 成本 :除了开发时间成本,可能需要投入一定的资源进行测试和维护。
  • 解决方案的可用性 :需要具备一定的编程能力和开发经验。
类库与可视化表单布局工具结合
  • 可维护性 :结合了类库的功能和可视化工具的便捷性,但可能存在兼容性问题,增加了维护的难度。
  • 灵活性 :在一定程度上实现了灵活性和可视化布局的平衡,但由于工具和类库的交互,灵活性有所限制。
  • 复杂表单支持 :可以较好地支持复杂表单的创建,但需要解决工具和类库之间的兼容性问题。
  • 浏览器兼容性 :取决于可视化工具和类库生成的代码,需要进行兼容性测试。
  • 可视化布局能力 :可以充分利用可视化工具的布局功能。
  • 外观控制 :可以通过可视化工具和类库的配合实现一致的外观。
  • 可访问性选项 :需要开发者在工具和类库中考虑可访问性问题。
  • 客户端验证 :可以结合类库和可视化工具的功能实现客户端验证。
  • 服务器端验证 :可以在服务器端进行验证。
  • 数据绑定 :需要解决类库和可视化工具之间的数据绑定问题。
  • 开发者效率 :开发速度较快,但需要掌握可视化工具和类库的使用方法。
  • 性能 :性能取决于工具和类库的实现质量。
  • 成本 :可能需要购买可视化工具和类库的许可证。
  • 解决方案的可用性 :需要确保工具和类库的兼容性和可用性。

以下是各解决方案属性评估的总结表格:
| 解决方案 | 可维护性 | 灵活性 | 复杂表单支持 | 浏览器兼容性 | 可视化布局能力 | 外观控制 | 可访问性选项 | 客户端验证 | 服务器端验证 | 数据绑定 | 开发者效率 | 性能 | 成本 | 解决方案可用性 |
| — | — | — | — | — | — | — | — | — | — | — | — | — | — | — |
| 手工编码表单 | 低 | 高 | 低 | 高 | 低 | 低 | 低 | 低 | 低 | 低 | 低 | 高 | 低 | 高 |
| 手工编码加脚本 | 中 | 中 | 中 | 高 | 中 | 中 | 中 | 中 | 中 | 中 | 中 | 中 | 中 | 中 |
| 使用wwShowCursor类 | 中 | 低 | 低 | 高 | 低 | 低 | 低 | 低 | 低 | 低 | 高 | 高 | 低 | 高 |
| 使用wwForm和wwCtls类 | 中 | 中 | 中 | 低 | 高 | 中 | 中 | 中 | 中 | 中 | 中 | 低 | 低 | 中 |
| 使用Voodoo Web Controls | 高 | 高 | 高 | 中 | 中 | 高 | 高 | 高 | 高 | 高 | 高 | 高 | 高 | 中 |
| 创建自己的类库 | 高 | 高 | 高 | 中 | 中 | 高 | 高 | 高 | 高 | 高 | 低 | 中 | 高 | 中 |
| 类库与可视化工具结合 | 中 | 中 | 中 | 中 | 高 | 高 | 中 | 中 | 中 | 中 | 高 | 中 | 高 | 中 |

总结

在Web数据库应用开发中,可扩展性和数据录入是两个关键的方面。提升Web应用可扩展性的策略有多种,包括在Web服务器上添加实例、利用额外网络机器分担负载、将数据迁移到不同后端、扩展到Web农场以及进一步物理分层等。每种策略都有其优点和适用场景,开发者需要根据系统的具体情况进行选择。

在数据录入方面,有多种解决方案可供选择,每种方案都有其特点和适用范围。开发者在选择解决方案时,应综合考虑可维护性、灵活性、复杂表单支持、浏览器兼容性等多个属性。例如,如果对灵活性要求较高,可选择手工编码表单;如果注重开发效率和数据绑定功能,Voodoo Web Controls是一个不错的选择。

总之,通过合理选择可扩展性策略和数据录入解决方案,可以提高Web应用的性能和开发效率,满足不同用户的需求,为用户提供更好的体验。同时,开发者应不断关注技术的发展,及时调整和优化自己的开发方案,以适应不断变化的业务需求。

希望本文对您在Web数据库应用开发中有所帮助,祝您开发顺利!

评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值