数据层组件设计及其数据传递的实现简介

haidong

<p ><B>适用于：</b><p >Microsoft&reg; .NET 应用程序<p ><B>摘要：</b><p >学习向 Microsoft .NET 应用程序公开数据的最佳方式，以及如何实现一个有效的策略以便在分布式应用程序的层间传递数据。（本文包含一些指向英文站点的链接。）<p ><B>目录</b><p ><ul><li>简介<p ><li>将关系数据映射到业务实体<p ><li>实现数据访问逻辑组件<p ><li>实现业务实体<p ><li>事务处理<p ><li>验证<p ><li>异常管理<p ><li>授权与安全性<p ><li>部署<p ><li>附录及其合作者</UL>在设计分布式应用程序时需要确定如何访问和表示与该应用程序相关联的业务数据。本文提供一些指导原则以帮助您选择公开数据、保持数据和在应用程序的层间传递数据的最佳方式。<p >图1  所示为分布式应用程序中的常见层。本文区分业务数据与使用这些数据的业务过程，并且仅在需要明确说明时讨论业务过程层。同样，本文仅在直接涉及数据表示方式（例如 Microsoft&reg; ASP.NET Web 页面公开业务数据的方式）时讨论表示层。图1 中使用了两个新术语：数据访问逻辑组件和业务实体组件。本文后面将解释这些术语。<p ><center><img  src="http://www.hh010.com/upload_files/article/244/9_6xdvfi263714.gif"><p >图1：分布式应用程序中数据的访问与表示</center><p >多数应用程序将数据存储在关系数据库中。除此之外还有其他数据存储方式，但本文重点讨论 .NET 应用程序与关系数据库交互的方式，而并不专门讨论它如何与平面文件、非关系数据库等其他数据存储中的数据进行交互。<p >本文明确区分保持逻辑与数据本身。将保持逻辑与数据区分开来的原因如下：<p ><ul><li>独立的数据保持组件可以将应用程序与数据源名称、连接信息、字段名等数据库相关内容隔离开。 <p ><li>现在的许多应用程序都采用XML Web services、Microsoft消息队列（亦称 MSMQ）等松散耦合的、基于消息的技术。这些应用程序通常通过传递业务文档而不是传递对象进行通信。</ul><B>注意：</b>有关XML Web services的介绍，请参阅MSDN&reg; Magazine 2002年3月号中的文章 .NET Web Services: Web Methods Make it Easy to Publish Your App's Interface over the Internet。有关消息队列的详细信息，请参阅“Message Queuing Overview”。<p >为区分保持逻辑与数据本身，本文提出了两种不同的组件类型。<p ><ul><li>数据访问逻辑组件。数据访问逻辑组件从数据库中检索数据并把实体数据保存回数据库中。数据访问逻辑组件还包含实现数据相关操作所需的所有业务逻辑。 <p ><li>业务实体组件。数据用来表示产品、订单等现实世界中的业务实体。在应用程序中表示这种业务实体的方法非常多，例如 XML、DataSet、面向对象的自定义类等，这取决于应用程序的物理和逻辑设计限制。本文后面将详细讨论各种设计方案。</ul><B>数据访问逻辑组件</b><p >数据访问逻辑组件代表调用程序提供对数据库执行以下任务的方法：<p ><ul><li>在数据库中创建记录 <p ><li>读取数据库中的记录并把业务实体数据返回给调用程序 <p ><li>使用调用程序提供的修改后的业务实体数据更新数据库中的记录 <p ><li>删除数据库中的记录 </ul>执行上述任务的方法通常称为“CRUD”方法，这是由各项任务的首字母组成的一个缩写词。<p >数据访问逻辑组件还提供对数据库实现业务逻辑的方法。例如，数据访问逻辑组件可能包含一个查找目录中本月销售额最高的产品的方法。<p >通常，数据访问逻辑组件访问一个单一数据库，并封装了针对该数据库中一个表或一组相关表的数据相关操作。例如，可以定义一个数据访问逻辑组件来处理数据库中的 Customer 表和 Address 表，同时定义另一个数据访问逻辑组件来处理 Orders 表和 OrderDetails 表。本文后面将讨论将数据访问逻辑组件映射到数据库表的设计决策。<p ><B>表示业务实体</b><p >每个数据访问逻辑组件都处理一种特定类型的业务实体。例如，Customer 数据访问逻辑组件处理 Customer 业务实体。表示业务实体的方式很多，这取决于诸如以下因素：<p ><ul><li>是否需要把业务实体数据与 Microsoft Windows&reg; 窗体或 ASP.NET 页面中的控件绑定在一起？ <p ><li>是否需要对业务实体数据执行排序或搜索操作？ <p ><li>应用程序是每次处理一个业务实体，还是通常处理一组业务实体？ <p ><li>是本地部署还是远程部署应用程序？ <p ><li>XML Web services 是否使用该业务实体？ <p ><li>性能、可缩放性、可维护性、编程方便性等非功能性要求的重要程度如何？</ul>本文将概述以下实现选项的优缺点：<p ><ul><li>XML。使用 XML 字符串或 XML 文档对象模型 (DOM) 对象来表示业务实体数据。XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。 <p ><li>DataSet。DataSet 是缓存在内存中的表，它是从关系数据库或 XML 文档中获得的。数据访问逻辑组件可以使用 DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该 DataSet。有关 DataSet 的介绍，请参阅 .NET Data Access Architecture Guide 中的“Introducing ADO.NET”。 <p ><li>有类型的 DataSet。有类型的 DataSet 是从 ADO.NET DataSet 类继承而来的类，它为访问表和 DataSet 中的列提供了具有严格类型的方法、事件和属性。 <p ><li>业务实体组件。这是一种自定义类，用于表示各种业务实体类型。您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。此选项并不通过CRUD方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行CRUD操作。 <p ><li>带有CRUD行为的业务实体组件。按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的CRUD方法。</ul><B>注意：</b>如果希望以一种更加面向对象的方式使用数据，可以使用另一种替代方法，即定义一个基于公共语言运行库的反射功能的对象保持层。您可以创建一个使用反射功能来读取对象属性的架构，并使用映射文件来描述对象与表之间的映射。然而，要有效地实现上述方法，需要大量的基础结构代码投入。对于 ISV 和解决方案提供商来说，这种投入或许可以接受，但对于大多数组织则不可行。有关这方面的讨论超出了本文的范围，这里不再论述。<p ><B>技术因素</b><p >图2 所示为影响数据访问逻辑组件和业务实体实现策略的一些技术因素。本文将分别讨论这些技术因素并提供相关建议。<p ><center><img  src="http://www.hh010.com/upload_files/article/244/9_wnuq0n263715.gif"><p >图2：影响数据访问逻辑组件和业务实体设计的技术因素</center><p >                                 <p align="center"></p></p>