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

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

数据层组件设计与数据传递

摘要:

学习向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:假想的关系数据库中的表关系

下表总结了示例数据库中的关系类型。

当定义业务实体以在数据库中建立信息模型时,应考虑要如何在您的应用程序中使用这些信息。应当标识封装您的应用程序的功能的核心业务实体,而不是为每个表定义单独的业务实体。

该假想零售商的应用程序中的典型操作如下:

∙获取(或更新)客户的有关信息(包括地址)

∙获取客户的订单列表

∙获取特定订单的订购项目列表

∙创建新订单

∙获取(或更新)一个或一组产品的有关信息

相关文档
最新文档