访问存储数据

　　ADO 能够方便地构建重型客户端，但客户端的伸缩性较差，ADO.NET 与 ADO 不同，它更适用于构建轻型客户端。ADO.NET 客户端使用仅向前的只读游标读取数据。它不支持有状态的服务器端游标，因此其编程模式鼓励短时间的连接。直接读取和处理数据的客户端可以使用 ADO.NET 的 DataReader 对象，它不为返回的数据提供缓存。或者，可以将数据读入 DataSet 对象中，将其作为从 SQL 查询和其他源中返回的数据的缓存。但是，与 ADO 记录集不同，数据集不能显式地维护与数据库的开放连接。

　　如前面所述，ADO 生成的重型方法还存在一些其他问题。这些问题可以在 ADO.NET 中解决，如下所示：

　　●对于将数据存储在数据集并要求访问由其他用户或应用程序所做的更改的 ADO.NET 客户端，需要包含显式代码才能进行这些更改。该代码通常还需要为每个所进行的检查打开一个数据库连接。

　　●尽管 ADO.NET 并不直接支持保守式锁定，但通过使用 ADO.NET 事务或在存储过程中实现所需的功能，客户端仍然可以获得同样的效果。

　　●与 ADO 不同，ADO.NET 不允许将部分查询结果保留在数据库中(可以使用服务器端游标从中进行访问)。虽然 ADO.NET 确实比 ADO 检索的元数据要少，但应用程序仍应设计为能够将所有的查询结果从数据库传递到 ADO.NET 客户端。

　　ADO.NET 中影响体系结构选择的另一项更改是其对处理分层数据(特别是 XML 文档)的支持增强了。将 ADO.NET 数据集转换成 XML 非常简单，就象访问 SQL Server 2000 的 XML 功能一样。因此，在 Windows DNA 中可能被强制装入关系模型中的分层数据现在可以以其原始形式提供访问。

　　将数据传递到客户端

　　将数据有效地传递到客户端对于在 .net 框架上构建的 N 层应用程序和使用 Windows DNA 构建的应用程序同样重要。一项重要的更改在于，ADO.NET 数据集可自动序列化成 XML，从而使得各层之间的数据传递更加简单。虽然在 Windows DNA 中也可以使用这种方法，但 .NET 使通过 XML 的信息交换变得更加简单、直接。

　　XML Web Services 体系结构

　　在构建分布式应用程序的过程中，可以通过多种方法来使用 XML Web services 的 SOAP、Web Services 说明语言 (WSDL) 以及其他技术。例如：

　　●使用 SOAP 而不是仅仅使用 HTTP 连接到 N 层应用程序的 Web 客户端。连接建立后，该客户端可以是能够进行 SOAP 调用的任意设备。之后，客户端可以为其用户提供更多的功能，因为它能够直接调用远程服务器中的方法。

　　●将可能是在基于 .NET 框架的平台上构建的 N 层应用程序与在其他平台(例如 Java 应用程序服务器)上构建的另一个应用程序连接起来。

　　●连接两个大型应用程序，或者连接一个企业资源规划 (ERP) 系统与另一个 ERP 系统或任何其他应用程序。正如这些示例所示，XML Web services 不仅仅适用于 N 层应用程序，其应用范围十分广阔。

　　不管如何使用，XML Web services 都会带来许多新的体系结构问题。XML Web services 与 N 层应用程序通常使用的更为传统的中间件技术之间的最主要的差别或许在于，XML Web services 提供的是“松散耦合”。遗憾的是，这个词对于不同的用户有着不同的含义。在本文中，它是指具有以下特点的通信应用程序：

　　●应用程序在很大程度上相互独立，并且通常由不同的组织控制。

　　●并不完全可靠。不能保证每个通信应用程序在所有时间都可用。

　　●其交互操作可以是同步的，也可以是异步的。Web services 客户端可能阻塞对某个请求的响应的等待，也可以在发出请求后去做其他事，稍后再来检查响应。

　　●这些基本特点为使用 XML Web services 的应用程序提供了很多体系结构方面的原则。虽然有些问题可能会在以后的工作中得到解决，如 Microsoft 的 Global XML Web Services Architecture (GXA) specifications(英文)，但是目前，创建有效的 XML Web services 应用程序的用户必须要了解这些问题。其中包括：

　　●安全性可能会比较复杂。预先规划端对端身份验证和有效授权十分重要。端对端的数据完整性和数据保密性对某些应用程序也很重要。可能有必要在不同的安全机制之间进行映射，当然最好尽量避免这种情况。互操作性可能会成为问题。由于规范还相对不成熟，不同供应商的 SOAP 实现还不能始终很好地协作。

　　●修改现有应用程序以便可以通过 XML Web services 进行访问时，可能会出现问题。当把从未打算要在一起使用的程序连接在一起时，总会出现速度、可伸缩性和安全性等问题。现有应用程序通常不是作为服务器而构建的，因此处理一些很小的请求就会轻易搞垮它们。减少请求数量，而增加每个请求中包含的数据可能会提高应用程序的性能。此外，现有应用程序通常不能处理预料之外的负载，例如向 Internet 公开软件时可能产生的负载。如果可能，使用某种排队机制以在请求被响应之前将请求存储起来，这可能会有所帮助。

　　●调节故障非常重要。尤其是只需要一次语义的请求，通常需要格外小心。例如，请求可能会超时，从而触发重试，但原来的请求可能只是因为某种原因被延迟而已。如果针对单个调用执行两次远程 Web service 会出现问题，则必须创建某种机制来解决这个问题。

　　●不可能提供依赖于分布式锁定(跨越组织边界保持)的端对端事务。大多数组织不允许“外来”应用程序锁定数据，因此不可能实现两阶段提交样式的事务。而只能考虑为任何必要的回滚使用补偿事务。

　　●由于收到的数据可能跨越应用程序和组织边界，Web services 通信的每一端可能都需要仔细检查该数据。虽然应用程序的创建者可能十分信任由他们自己的应用程序的其他部分所生成的数据的准确性，但他们不能对其他应用程序抱以同样的信任。收到的信息甚至可能包含恶意代码，因此必须仔细检查。

　　●SOAP 及其携带的 XML 定义的数据非常多。在一个调用中传递太多数据可能会搞垮低带宽的网络。反过来，在一个调用中传递的数据太少又会搞垮处理这些请求的应用程序。尽管这很困难，但找到正确的平衡点还是很重要的。

　　小结

　　体系结构是关键。为应用程序(尤其是分布于多个系统的应用程序)选择正确的结构是至关重要的。如果选择了错误的体系结构，不管开发人员多么优秀，通常都无法在实现过程中修复。错误的决定会导致性能降低、安全性降低以及应用程序需要更新时可用的选项较少。

　　Windows DNA 为 N 层应用程序奠定了一个坚实的基础，Windows 开发人员可以根据他们从 DNA 领域所学到的知识来构建应用程序，把其中的大部分应用到新的 .NET 环境中。不过，了解本文所建议的更改将有助于创建更快、更安全、功能更强的应用程序。对于 N 层应用程序以及采用 Web services 新技术的应用程序来说，。NET 可提供的功能很多。

　　本文转载自CSDN BLOG,原文地址:http://blog.csdn.net/iwascat/archive/2007/01/23/1490902.aspx

上一页  [1] [2] [3]