B1架构的经典知识+三层架构的经典知识

数据层组件设计与数据传递摘要：学习向Microsoft .NET 应用程序公开数据的最佳方式，以及如何实现一个有效的策略以便在分布式应用程序的层间传递数据。

简介在设计分布式应用程序时需要确定如何访问和表示与该应用程序相关联的业务数据。

本文提供一些指导原则以帮助您选择公开数据、保持数据和在应用程序的层间传递数据的最佳方式。

图 1 所示为分布式应用程序中的常见层。

本文区分业务数据与使用这些数据的业务过程，并且仅在需要明确说明时讨论业务过程层。

同样，本文仅在直接涉及数据表示方式（例如Microsoft® Web 页面公开业务数据的方式）时讨论表示层。

图 1 中使用了两个新术语：数据访问逻辑组件和业务实体组件。

本文后面将解释这些术语。

图1：分布式应用程序中数据的访问与表示多数应用程序将数据存储在关系数据库中。

除此之外还有其他数据存储方式，但本文重点讨论 .NET 应用程序与关系数据库交互的方式，而并不专门讨论它如何与平面文件、非关系数据库等其他数据存储中的数据进行交互。

本文明确区分保持逻辑与数据本身。

将保持逻辑与数据区分开来的原因如下：独立的数据保持组件可以将应用程序与数据源名称、连接信息、字段名等数据库相关内容隔离开。

∙现在的许多应用程序都采用XML Web services、Microsoft 消息队列（亦称MSMQ）等松散耦合的、基于消息的技术。

这些应用程序通常通过传递业务文档而不是传递对象进行通信。

为区分保持逻辑与数据本身，本文提出了两种不同的组件类型。

∙数据访问逻辑组件。

数据访问逻辑组件从数据库中检索数据并把实体数据保存回数据库中。

数据访问逻辑组件还包含实现数据相关操作所需的所有业务逻辑。

∙业务实体组件。

数据用来表示产品、订单等现实世界中的业务实体。

在应用程序中表示这种业务实体的方法非常多，例如XML、DataSet、面向对象的自定义类等，这取决于应用程序的物理和逻辑设计限制。

本文后面将详细讨论各种设计方案。

数据访问逻辑组件数据访问逻辑组件代表调用程序提供对数据库执行以下任务的方法：∙在数据库中创建记录∙读取数据库中的记录并把业务实体数据返回给调用程序∙使用调用程序提供的修改后的业务实体数据更新数据库中的记录∙删除数据库中的记录执行上述任务的方法通常称为“CRUD”方法，这是由各项任务的首字母组成的一个缩写词。

数据访问逻辑组件还提供对数据库实现业务逻辑的方法。

例如，数据访问逻辑组件可能包含一个查找目录中本月销售额最高的产品的方法。

通常，数据访问逻辑组件访问一个单一数据库，并封装了针对该数据库中一个表或一组相关表的数据相关操作。

例如，可以定义一个数据访问逻辑组件来处理数据库中的Customer 表和Address 表，同时定义另一个数据访问逻辑组件来处理Orders 表和OrderDetails 表。

本文后面将讨论将数据访问逻辑组件映射到数据库表的设计决策。

表示业务实体每个数据访问逻辑组件都处理一种特定类型的业务实体。

例如，Customer 数据访问逻辑组件处理Customer 业务实体。

表示业务实体的方式很多，这取决于诸如以下因素：∙是否需要把业务实体数据与Microsoft Windows® 窗体或 页面中的控件绑定在一起？∙是否需要对业务实体数据执行排序或搜索操作？∙应用程序是每次处理一个业务实体，还是通常处理一组业务实体？∙是本地部署还是远程部署应用程序？∙XML Web services 是否使用该业务实体？∙性能、可缩放性、可维护性、编程方便性等非功能性要求的重要程度如何？本文将概述以下实现选项的优缺点：∙XML。

使用XML 字符串或XML 文档对象模型（DOM）对象来表示业务实体数据。

XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。

∙DataSet。

DataSet 是缓存在内存中的表，它是从关系数据库或XML 文档中获得的。

数据访问逻辑组件可以使用DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该DataSet。

∙有类型的DataSet。

有类型的DataSet 是从 DataSet 类继承而来的类，它为访问表和DataSet 中的列提供了具有严格类型的方法、事件和属性。

∙业务实体组件。

这是一种自定义类，用于表示各种业务实体类型。

您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。

此选项并不通过CRUD 方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行CRUD 操作。

∙带有CRUD 行为的业务实体组件。

按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的CRUD 方法。

注意：如果希望以一种更加面向对象的方式使用数据，可以使用另一种替代方法，即定义一个基于公共语言运行库的反射功能的对象保持层。

您可以创建一个使用反射功能来读取对象属性的架构，并使用映射文件来描述对象与表之间的映射。

然而，要有效地实现上述方法，需要大量的基础结构代码投入。

对于ISV 和解决方案提供商来说，这种投入或许可以接受，但对于大多数组织则不可行。

有关这方面的讨论超出了本文的范围，这里不再论述。

技术因素图 2 所示为影响数据访问逻辑组件和业务实体实现策略的一些技术因素。

本文将分别讨论这些技术因素并提供相关建议。

图2：影响数据访问逻辑组件和业务实体设计的技术因素将关系数据映射到业务实体数据库通常包含许多表，这些表之间的关系通过主键和外键来实现。

当定义业务实体以在 .NET 应用程序中表示这些数据时，必须确定如何把这些表映射到业务实体。

请考虑图 3 所示的假想零售商数据库。

图3：假想的关系数据库中的表关系下表总结了示例数据库中的关系类型。

当定义业务实体以在数据库中建立信息模型时，应考虑要如何在您的应用程序中使用这些信息。

应当标识封装您的应用程序的功能的核心业务实体，而不是为每个表定义单独的业务实体。

该假想零售商的应用程序中的典型操作如下：∙获取（或更新）客户的有关信息（包括地址）∙获取客户的订单列表∙获取特定订单的订购项目列表∙创建新订单∙获取（或更新）一个或一组产品的有关信息为满足这些应用程序要求，该应用程序要处理三个逻辑业务实体：Customer、Order 和Product。

对于每个业务实体，都将定义一个单独的数据访问逻辑组件，如下所示：∙Customer 数据访问逻辑组件。

此类将为检索和修改Customer 表和Address 表中的数据提供服务。

∙Order 数据访问逻辑组件。

此类将为检索和修改Order 表和OrderDetails 表中的数据提供服务。

∙Product 数据访问逻辑组件。

此类将为检索和修改Product 表中的数据提供服务。

图 4 所示为这些数据访问逻辑组件与它们所表示的数据库中的表之间的关系。

图4：定义向 .NET 应用程序公开关系数据的数据访问逻辑组件将关系数据映射到业务实体的建议要将关系数据映射到业务实体，请考虑以下建议：∙花些时间来分析您的应用程序的逻辑业务实体并为之建立模型，不要为每个表定义一个单独的业务实体。

建立应用程序的工作方式模型的方法之一是使用统一建模语言（UML）。

UML 是一种形式设计注释，用于在面向对象的应用程序中建立对象模型，并获取有关对象如何表示自动过程、人机交互以及关联的信息。

∙不要定义单独的业务实体来表示数据库中的多对多表，可以通过在数据访问逻辑组件中实现的方法来公开这些关系。

例如，前面示例中的OrderDetails 表没有映射到单独的业务实体，而是通过在Order 数据访问逻辑组件中封装OrderDetails 表来实现Order 与Product 表之间的多对多关系。

∙如果具有返回特定业务实体类型的方法，请把这些方法放在该类型对应的数据访问逻辑组件中。

例如，当检索一个客户的全部订单时，返回值为Order 类型，因此应在Order 数据访问逻辑组件中实现该功能。

反之，当检索订购某特定产品的全部客户时，应在Customer 数据访问逻辑组件中实现该功能。

∙数据访问逻辑组件通常访问来自单一数据源的数据。

当需要聚合多个数据源的数据时，建议分别为访问每个数据源定义一个数据访问逻辑组件，这些组件可以由一个能够执行聚合任务的更高级业务过程组件来调用。

建议采用这种方法的原因有二：∙事务管理集中在业务过程组件中，不需要由数据访问逻辑组件显式控制。

如果通过一个数据访问逻辑组件访问多个数据源，则需要把该数据访问逻辑组件作为事务处理的根，这会给仅读取数据的功能带来额外的系统开销。

∙通常，并不是应用程序的所有区域都需要聚合，并且通过分离对数据的访问，您可以单独使用该类型，也可以在必要时将其用作聚合的一部分。

数据访问逻辑组件是一个无状态类，也就是说，所交换的所有消息都可以独立解释。

调用之间不存在状态。

数据访问逻辑组件为访问单一数据库（某些情况下可以是多个数据库，例如水平数据库分区）中的一个或多个相关表提供方法。

通常，数据访问逻辑组件中的这些方法将调用存储过程以执行相应操作。

数据访问逻辑组件的主要目标之一是从调用应用程序中隐藏数据库的调用及格式特性。

数据访问逻辑组件为这些应用程序提供封装的数据访问服务。

具体地说，数据访问逻辑组件处理以下实现细节：∙管理和封装锁定模式∙正确处理安全性和授权问题∙正确处理事务处理问题∙执行数据分页∙必要时执行数据相关路由∙为非事务性数据的查询实现缓存策略（如果适用）∙执行数据流处理和数据序列化本节后面将详细讨论其中的某些问题。

数据访问逻辑组件的应用方案图 5 所示为从各种应用程序类型（包括Windows 窗体应用程序、 应用程序、XML Web services 和业务过程）中调用数据访问逻辑组件的方式。

根据应用程序的部署方式，这些调用可以是本地的，也可以是远程的。

图5：数据访问逻辑组件的应用方案数据访问逻辑组件使用 执行SQL 语句或调用存储过程。

如果您的应用程序包含多个数据访问逻辑组件，可以使用数据访问助手组件来简化数据访问逻辑组件类的实现。

该组件可以帮助管理数据库连接、执行SQL 命令以及缓存参数。

数据访问逻辑组件仍然封装访问特定业务数据所需的逻辑，而数据访问助手组件则专注于数据访问API 的开发和数据连接配置，从而帮助减少代码的重复。

当使用Microsoft SQL Server™ 数据库时，可在您的应用程序中将其用作一个通用的数据访问助手组件。

图 6 所示为使用数据访问助手组件帮助实现数据访问逻辑组件的方法。

图6：使用数据访问助手组件实现数据访问逻辑组件当存在所有数据访问逻辑组件公用的实用程序功能时，可以定义一个基本类以从中继承和扩展数据访问逻辑组件。