SQL Server XML 和 Web 应用体系结构（二）

　　写入方物理体系结构SQL Server XML 模板经过高度流程化，能尽可能高效地通过 HTTP 访问数据库。为此付出的代价是功能集受到限制。在模板中找不到所需功能的情况下，SQL Server 的专用 ISAPI 应用被替换为 ASP、ASP 和 COM 的组合或自定义的 ISAPI 应用。本节中说明的体系结构适用于您的页面要执行下列操作的情况： 访问多个服务器上的数据库处理在设计时未知其格式的 HTTP 请求调用 COM/COM 对象使用 COM 事务连接至 Internet 上的任何应用或 Web 服务，例如付款提供程序 图 4：写入方体系结构Web 层上的代码表示应用功能的四个层——数据访问、业务逻辑、工作流和表示。在开发应用时，请确保此代码与体系结构保持一致。这可使代码的可读性更高，也更易于维护。如果决定单独使用 ASP，脚本类的效率会更高。如果在业务逻辑层或工作流层有大量复杂的处理，对这些层使用 COM 组件可能速度更快。相反，对于处理量相对较小的情况，使用脚本可能速度更快。这种新体系结构更出色的原因是，所有层（从数据到表示）都使用 XML 来传输和存储信息。数据库中的存储过程使用这些新功能来读写 XML。数据访问层利用 ADO 2.6 流与数据库进行高效、基于 XML 的通讯。更新颖的方法是将某些中间层下移到数据库中。以数据库为中心的体系结构Duwamish Online 体系结构基于这样一种设想：因为数据库的可伸缩性最低，它应该设计成执行尽可能少的任务。分布式分区视图等新功能允许在多个服务器之间分担工作量，从而提高了数据库的可伸缩性，使开发人员可以选择将大部分工作放在何处。如果选择将“脚重”服务器群集（数据库方面功能更强）与 SQL Server XML 体系结构一起使用，则另一种方法是使用与 n-层组件的分层方式相似的方式来对数据库中的存储过程进行分层。要实现这一点，必须有好的编程方法，例如选择适当的数据结构和尽可能避免重复代码。图 5：以数据库为中心的体系结构这种体系结构中的表示层还包含用于访问数据库中的存储过程的代码。此代码可能与传统数据访问层中的代码相同。但是，调用此代码时数据访问层可能会出错，因为这些例程调用工作流层提供的接口。在使用存储过程进行开发工作时应该小心避免出现缺陷。让我们先来看一个设计，这个设计使用了几个智能存储过程，它们先执行该层的公共任务，然后再执行在下一个层上继续执行其代码路径的逻辑切换。在工作流层中调用“智能过程”将对应于若干个不同的操作之一。此过程如下所示：CREATE PROCEDURE /* 这是一个智能过程，执行工作流操作 */DoWorkflow /* Action 用于选择该调用的多个操作之一 */ @Action nvarchar(255),/* SomeOtherParameters 是一个占位符，用于工作流所需的其他输入 */ @SomeOtherParameters ntextAS/* 执行工作流的公共操作 */Execute SomeCommonWorkflowOperationsIf @Action = N'Action1'BEGIN /* 执行 Action 1 */ Execute BusinessLogicAction1ENDElse If @Action = N'Action2'BEGIN /* 执行 Action 2 */ Execute BusinessLogicAction2ENDGO第一次调用此过程时，SQL Server 优化执行恰好第一次运行的任何代码路径。这使其余代码路径的运行效率降低，尽管它们的成本可能更高或者使用的频率更高。为确保优化执行所有代码路径，可为每个操作创建一个单独的过程，尽可能避免切换逻辑。为防止代码重复，所有层中多个操作共享的函数应该放在单独的过程中。当该设计产生大量过程时，优化可以大大提高应用的效率。集成Web 开发中最值得称道的一点是用户看不到实施过程。因此，本文中介绍的体系结构可以轻松地合并到单个应用中，而无需用户参与。下面是一些准则，可以帮助您更轻松地集成应用的不同部分： 在整个应用中使用 XML。XML 可以用于任何技术中，可以使用 XSL 样式表轻松地进行转换，还可以毫无困难地存储在任何地方。SQL Server XML 使得在您的应用中使用 XML 比以前更容易。尽可能分解代码。使用 XSL 样式表来转换 XML。可以在模板、COM 组件和一段脚本之间方便地共享同一个 XSL 样式表。当脚本执行多个函数时，使用脚本类分解代码。在数据库方面，始终使用存储过程进行数据访问。它们不仅易于维护，而且比未编译的 SQL 查询执行速度快得多。 影响本节说明使用新的体系结构对于您的应用在“功能”和性能方面有何影响。可编程性可编程性是指容易编写应用代码。通常反映在开发应用的时间而不是功能方面。以 Duwamish Online 应用为例。该应用的五个层是通过一组完全不同的技术来实现的。表示层使用了 C （用于缓存组件）和 Web 技术（例如 XML、XSL 和 ASP)。工作流层、业务逻辑层和数据访问层是 Visual Basic COM 组件，而数据库中的存储过程是用 T-SQL 编写的。使用这么多技术的优点是，开发人员可以针对每种类型的操作选择最佳技术。但是，要使所有组件高效地紧密协作无疑是一个难点。当使用多种不同的工具和不同的编程语言开发组件时，跨组件跟踪和调试始终非常困难。在整个应用中使用 SQL Server XML 将有助于最大程度地降低不同技术的工作量。（XSL 是一个例外：它不属于 SQL Server XML，但却紧密集成在 SQL Server XML 模板中）。各层之间一起工作，但产生的冲突最少。在各层之间进行调试非常简便，因为所有的中间数据都是 XML，无需任何额外操作。但是，可编程性的最大优点可能是大大减少了代码量：基于 SQL Server XML 版本的 Duwamish Books, Phase 4 可完成基于 COM 的同类产品相同的工作，但前者的代码量只有后者的十分之一。通过 SQL Server XML 的内置功能使数据访问、XML 转换、XSL 转换和数据缓存变得更加简便。遗憾的是，不能再使用 XSL 的高效调试工具，而用于其他新技术的调试工具相对来讲还不成熟（尤其是与 Microsoft Visual Studio® 提供的跨语言调试能力相比）。 可管理性SQL Server XML 应用易于部署。对于运行在 Web 层的代码，只需简单地将文件复制到它们的目标目录，然后运行一次配置工具以建立相应的虚拟目录。更新过程只是简单地替换过期的文件。可以使用 SQL Server Enterprise Manager 轻松地管理数据库对象。性能有关详细信息，请参阅 Duwamish Online SQL Server XML 分类浏览文章中有关性能的一节。使用建议有关新技术最重要的问题可能是使用的时机。尽管 SQL Server XML 不是所有 Internet 问题的最终解决方案，但是在某些情况下，其优势是显而易见的，这包括代码量大大减少、开发周期明显缩短、性能更高和维护更方便。新技术的两个主要组件（数据库和 ISAPI 应用）的使用情况不同，如下所述。SQL Server XML 的数据库服务器组件几乎用于所有应用。即使要将现有的应用从使用数据库转换为使用 XML 也是值得的。一些显著的优点如下： 易于本地化（使用 XSL）不依赖于平台和技术易于缓存 XML 数据能够使用脱机/断开连接的应用易于合并或创建 Web 服务能够与其他应用协同工作 新技术的 Web 界面组件是专用的。它们可提供对数据库的快速、高效访问，并提供使用 XSL 样式表轻松创建数据驱动页的能力。这些优点非常有用。在我们的测试中，Duwamish Online SQL Server XML 分类浏览（无缓存）比 Duwamish Online（有缓存）的性能高 15%。使用 SQL Server 2000 技术预览版进行的早期测试显示 SQL Server XML ISAPI 缓存可使性能有数量级的提高。但是，如果应用包含下列任何一种情况，则可以考虑使用基于 ASP 的中间层： 与数据提取无关的扩展业务逻辑例程。有两个选项决定这些例程的位置：数据库的存储过程或 XSL 中的脚本。脚本的效率不够高，而结构化查询语言 (SQL) 可能不是最佳语言。扩展字符串，尤其是结果集合的处理。此规则的例外情况是存储在 XML 或 HTML 数据库中的转义字符串。SQL Server 2000 的一个新功能将自动完成这项工作。有关详细信息，请参阅 SQL Server Books Online 文档（XML 和 Internet 支持 检索和编写 XML 数据 使用 FOR XML 检索 XML 文档 使用 EXPLICIT 模式 F. 指定 cdata 指令）。大量 HTML 输入。模板的局限性使其无法通过在设计时已知其格式的 HTTP 请求检索所有信息，此工作可以使用 ASP 页完成。 注意！SQL Server 2000 还允许通过 URL 直接访问数据库。在其他情况下，允许使用动态模板来帮助解决体系结构方面的很多问题。但是，如果启用此功能，将允许尝试删除数据库的查询，因此，如果选择使用此功能，请确保数据库的安全性无懈可击。总结SQL Server XML 提供了一种新的观念，通过允许从数据库直接检索 XML，使您的应用可以端对端使用 XML。新的 ISAPI 应用提供了令人满意的性能，但不一定适用于应用中的所有使用情况。