数据访问逻辑组件使用 ADO.NET 执行 SQL 语句或调用存储过程。
如果您的应用程序包含多个数据访问逻辑组件，可以使用数据访问助手组件来简化数据访问逻辑组件类的实现。该组件可以帮助管理数据库连接、执行 SQL 命令以及缓存参数。数据访问逻辑组件仍然封装访问特定业务数据所需的逻辑，而数据访问助手组件则专注于数据访问 API 的开发和数据连接配置，从而帮助减少代码的重复。当使用 Microsoft SQL Server™ 数据库时，可在您的应用程序中将其用作一个通用的数据访问助手组件。图 6 所示为使用数据访问助手组件帮助实现数据访问逻辑组件的方法。
图 6： 使用数据访问助手组件实现数据访问逻辑组件
当存在所有数据访问逻辑组件公用的实用程序功能时，可以定义一个基本类以从中继承和扩展数据访问逻辑组件。
将数据访问逻辑组件类设计为可以为不同类型的客户端提供一致的接口。如果将数据访问逻辑组件设计为与当前及潜在的业务过程层的实现要求相兼容，可以减少必须实现的附加接口、接触面或映射层的数目。
要支持广泛的业务过程和应用程序，请考虑以下技术以便将数据传入和传出数据访问逻辑组件方法：
- 将业务实体数据传递给数据访问逻辑组件中的方法。您可以用多种不同的格式传递数据：作为一系列标量值、作为 XML 字符串、作为 DataSet 或作为自定义业务实体组件。
- 从数据访问逻辑组件中的方法返回业务实体数据。您可以用多种不同的格式返回数据：作为输出参数标量值、作为 XML 字符串、作为 DataSet、作为自定义业务实体组件或作为数据读取器。
以下各节将说明用于将业务实体数据传入和传出数据访问逻辑组件的各种方式以及每种方式的优缺点。这些信息有助于您根据自己特定的应用程序方案做出相应选择。
将标量值作为输入和输出传递这种方法的优点如下：
- 抽象。调用程序只需要知道定义业务实体的数据，而不需要知道业务实体的具体类型或具体结构。
- 序列化。标量值本身支持序列化。
- 内存使用效率高。标量值只传递实际需要的数据。
- 性能。当处理实例数据时，标量值具有比本文所述的其他方法更高的性能。
这种方法的缺点如下：
- 紧密耦合与维护。架构的更改可能需要修改方法签名，这会影响调用代码。
- 实体集合。要向数据访问逻辑组件保存或更新多个实体，必须进行多次单独的方法调用。这在分布式环境中会给性能带来很大影响。
- 支持开放式并发。要支持开放式并发，必须在数据库中定义时间戳列并将其作为数据的一部分。
这种方法的优点如下：
- 松散耦合。调用程序只需要知道定义业务实体的数据和为业务实体提供元数据的架构。
- 集成。采用 XML 可以支持以各种方式（例如，.NET 应用程序、BizTalk Orchestration 规则和第三方业务规则引擎）实现的调用程序。
- 业务实体集合。一个 XML 字符串可以包含多个业务实体的数据。
- 序列化。字符串本身支持序列化。
这种方法的缺点如下：
- 需要重新分析 XML 字符串。必须在接收端重新分析 XML 字符串。很大的 XML 字符串会影响性能。
- 内存使用效率低。XML 字符串比较繁琐，因而在需要传递大量数据时会降低内存使用效率。
- 支持开放式并发。要支持开放式并发，必须在数据库中定义时间戳列并将其作为 XML 数据的一部分。
这种方法的优点如下：
- 固有功能。DataSet 提供了内置功能，可以处理开放式并发（以及数据适配器）并支持复杂的数据结构。此外，有类型的 DataSet 还提供了数据验证支持。
- 业务实体集合。DataSet 是为处理复杂的关系集合而设计的，因此不需要再编写自定义代码来实现这一功能。
- 维护。更改架构不会影响方法签名。然而，如果使用的有类型的 DataSet 和程序集具有严格名称，则必须按照新版本重新编译数据访问逻辑组件类，或在全局程序集缓存中使用发布者策略，或在配置文件中定义一个 ＜bindingRedirect＞ 元素。
- 序列化。DataSet 本身支持 XML 序列化，并且可以跨层序列化。
这种方法的缺点如下：
- 性能。实例化和封送处理 DataSet 会增加运行时负担。
- 表示单个业务实体。DataSet 是为处理一组数据而设计的。如果您的应用程序主要处理实例数据，则标量值或自定义实体是更好的方法，后者不会影响性能。
这种方法的优点如下：
- 维护。更改架构不会影响数据访问逻辑组件方法签名。然而，如果业务实体组件包含在严格命名的程序集中，就会出现与有类型的 DataSet 同样的问题。
- 业务实体集合。可以将自定义业务实体组件的数组和集合传入和传出方法。
这种方法的缺点如下：
- 支持开放式并发。要方便地支持开放式并发，必须在数据库中定义时间戳列并将其作为实例数据的一部分。
- 集成限制。当使用自定义业务实体组件作为数据访问逻辑组件的输入时，调用程序必须知道业务实体的类型，而这会限制不使用 .NET 的调用程序的集成。然而，如果调用程序使用自定义业务实体组件作为数据访问逻辑组件的输出，则上述问题并不会限制集成。例如，Web 方法可以返回从数据访问逻辑组件返回的自定义业务实体组件，并使用 XML 序列化自动将该业务实体组件序列化为 XML。
这种方法的优点如下：
- 性能。当需要快速呈现数据时，这种方法具有性能优势，并且可以使用表示层代码部署数据访问逻辑组件。
这种方法的缺点如下：
- 远程。建议不要在远程方案中使用数据读取器，因为它可能会使客户端应用程序与数据库保持长时间的连接。
可以使用存储过程执行数据访问逻辑组件支持的许多数据访问任务。
优点
- 存储过程通常可以改善性能，因为数据库能够优化存储过程使用的数据访问计划并为以后的重新使用缓存该计划。
- 可以在数据库内分别设置各个存储过程的安全保护。管理员可以授予客户端执行某个存储过程的权限，而不授予任何基础表访问权限。
- 存储过程可以简化维护，因为修改存储过程通常比修改所部署的组件中的硬编码 SQL 语句要容易。然而，随着在存储过程中实现的业务逻辑的增多，上述优势会逐渐减弱。
- 存储过程增大了从基础数据库架构进行抽象的程度。存储过程的客户端与存储过程的实现细节和基础架构是彼此分离的。
- 存储过程会降低网络流量。应用程序可以按批执行 SQL 语句而不必发出多个 SQL 请求。
尽管存储过程具有上述优点，但仍有某些情况不适合使用存储过程。
缺点- 如果逻辑全部在存储过程中实现，那么涉及广泛业务逻辑和处理的应用程序可能会给服务器带来过重负荷。这类处理包括数据传输、数据遍历、数据转换和大计算量操作。应把这类处理移到业务过程或数据访问逻辑组件中，与数据库服务器相比，它们具有更好的可缩放性。
- 不要把所有业务逻辑都放在存储过程中。如果必须在 T - SQL 中修改业务逻辑，应用程序的维护和灵活性将成为问题。例如，支持多个 RDBMS 的 ISV 应用程序不应当分别为每个系统维护存储过程。
- 通常，存储过程的编写与维护是一项专门技能，并非所有开发人员都能够掌握。这会造成项目开发计划的瓶颈。
