(转载)表示业务实体的几种方式比较分析

原文： 设计数据层组件并在层间传递数据
URL:  http://www.microsoft.com/china/msdn/archives/library/dnbda/html/BOAGag.asp
作者：Angela Crocker、Andy Olsen , Edward Jezierski 

表示业务实体

每个数据访问逻辑组件都处理一种特定类型的业务实体。例如，Customer 数据访问逻辑组件处理 Customer 业务实体。表示业务实体的方式很多，这取决于诸如以下因素：

• 是否需要把业务实体数据与 Microsoft Windows® 窗体或 ASP.NET 页面中的控件绑定在一起？
• 是否需要对业务实体数据执行排序或搜索操作？
• 应用程序是每次处理一个业务实体，还是通常处理一组业务实体？
• 是本地部署还是远程部署应用程序？
• XML Web services 是否使用该业务实体？
• 性能、可缩放性、可维护性、编程方便性等非功能性要求的重要程度如何？

本文将概述以下实现选项的优缺点：

• XML。使用 XML 字符串或 XML 文档对象模型 (DOM) 对象来表示业务实体数据。XML 是一种开放而灵活的数据表示格式，可用于集成各种类型的应用程序。
• DataSet。DataSet 是缓存在内存中的表，它是从关系数据库或 XML 文档中获得的。数据访问逻辑组件可以使用 DataSet 来表示从数据库中检索到的业务实体数据，您可以在应用程序中使用该 DataSet。有关 DataSet 的介绍，请参阅 .NET Data Access Architecture Guide 中的“Introducing ADO.NET”。
• 有类型的 DataSet。有类型的 DataSet 是从 ADO.NET DataSet 类继承而来的类，它为访问表和 DataSet 中的列提供了具有严格类型的方法、事件和属性。
• 业务实体组件。这是一种自定义类，用于表示各种业务实体类型。您可以定义保存业务实体数据的字段，并定义将此数据向客户端应用程序公开的属性，然后使用在该类中定义的字段来定义方法以封装简单的业务逻辑。此选项并不通过 CRUD (create, retrieve, update, and delete)方法实现与基础数据访问逻辑组件的数据传递，而是通过客户端应用程序直接与数据访问逻辑组件进行通信以执行 CRUD 操作。
• 带有 CRUD 行为的业务实体组件。按上述方法定义一个自定义实体类，并实现调用与此业务实体相关联的基础数据访问逻辑组件的 CRUD 方法。 

注意：如果希望以一种更加面向对象的方式使用数据，可以使用另一种替代方法，即定义一个基于公共语言运行库的反射功能的对象保持层。您可以创建一个使用反射功能来读取对象属性的架构，并使用映射文件来描述对象与表之间的映射。然而，要有效地实现上述方法，需要大量的基础结构代码投入。对于 ISV 和解决方案提供商来说，这种投入或许可以接受，但对于大多数组织则不可行。有关这方面的讨论超出了本文的范围，这里不再论述。

将关系数据映射到业务实体的建议

要将关系数据映射到业务实体，请考虑以下建议：

• 花些时间来分析您的应用程序的逻辑业务实体并为之建立模型，不要为每个表定义一个单独的业务实体。建立应用程序的工作方式模型的方法之一是使用统一建模语言 (UML)。UML 是一种形式设计注释，用于在面向对象的应用程序中建立对象模型，并获取有关对象如何表示自动过程、人机交互以及关联的信息。有关详细信息，请参阅 Modeling Your Application and Data。
• 不要定义单独的业务实体来表示数据库中的多对多表，可以通过在数据访问逻辑组件中实现的方法来公开这些关系。例如，前面示例中的 OrderDetails 表没有映射到单独的业务实体，而是通过在 Order 数据访问逻辑组件中封装 OrderDetails 表来实现 Order 与 Product 表之间的多对多关系。
• 如果具有返回特定业务实体类型的方法，请把这些方法放在该类型对应的数据访问逻辑组件中。例如，当检索一个客户的全部订单时，返回值为 Order 类型，因此应在 Order 数据访问逻辑组件中实现该功能。反之，当检索订购某特定产品的全部客户时，应在 Customer 数据访问逻辑组件中实现该功能。
• 数据访问逻辑组件通常访问来自单一数据源的数据。当需要聚合多个数据源的数据时，建议分别为访问每个数据源定义一个数据访问逻辑组件，这些组件可以由一个能够执行聚合任务的更高级业务过程组件来调用。建议采用这种方法的原因有二：
  • 事务管理集中在业务过程组件中，不需要由数据访问逻辑组件显式控制。如果通过一个数据访问逻辑组件访问多个数据源，则需要把该数据访问逻辑组件作为事务处理的根，这会给仅读取数据的功能带来额外的系统开销。
  • 通常，并不是应用程序的所有区域都需要聚合，并且通过分离对数据的访问，您可以单独使用该类型，也可以在必要时将其用作聚合的一部分。

实现业务实体

业务实体具有以下特点：

• 业务实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。
• 业务实体可以使用具有复杂架构的数据来构建。这种数据通常来自数据库中的多个相关表。
• 业务实体数据可以作为业务过程的部分 I/O 参数传递。
• 业务实体可以是可序列化的，以保持它们的当前状态。例如，应用程序可能需要在本地磁盘、桌面数据库（如果应用程序脱机工作）或消息队列消息中存储实体数据。
• 业务实体不直接访问数据库。全部数据库访问都是由相关联的数据访问逻辑组件提供的。
• 业务实体不启动任何类型的事务处理。事务处理由使用业务实体的应用程序或业务过程来启动。

如本文前面所述，在您的应用程序中表示业务实体的方法有很多（从以数据为中心的模型到更加面向对象的表示法）：

• XML
• 通用 DataSet
• 有类型的 DataSet
• 自定义业务实体组件
• 带有 CRUD 行为的自定义业务实体组件

以下各节将介绍如何使用这些格式来表示业务实体。为帮助您确定特定环境中最适宜的业务实体表示，以下各节将介绍如何为各业务实体格式执行以下任务：

• 组织业务实体集合
• 将业务实体数据绑定到用户界面控件
• 序列化业务实体数据
• 在层间传递业务实体数据

以下各节还针对非功能性要求（包括性能、效率、可缩放性和可扩展性）考虑了每种业务实体表示的适用性。

将业务实体表示为 XML

以下示例显示了如何将一个简单的业务实体表示为 XML。该业务实体包含一个产品。

<?xml version="1.0"?>
<Product xmlns="urn:aUniqueNamespace">
  <ProductID>1</ProductID>
  <ProductName>Chai</ProductName>
  <QuantityPerUnit>10 boxes x 20 bags</QuantityPerUnit>
  <UnitPrice>18.00</UnitPrice>
  <UnitsInStock>39</UnitsInStock>
  <UnitsOnOrder>0</UnitsOnOrder>
  <ReorderLevel>10</ReorderLevel>
</Product>

当使用 XML 表示业务实体数据时，请考虑以下原则：

• 确定 XML 文档是包含单个业务实体还是包含一个业务实体集合。前面的示例表示的是单个 Product 业务实体。
• 使用一个命名空间唯一标识该 XML 文档，以避免与其他 XML 文档的内容发生命名冲突。前面的示例使用名为 urn:aUniqueNamespace 的默认命名空间。
• 为元素和属性选择合适的名称。前面的示例使用 Product 表的列名称，但并不要求一定这样。可以选择对您的应用程序有意义的名称。
• 使用以下方法之一以 XML 格式检索您的业务实体：
  • 如果您使用的是 SQL Server 2000，则可以在查询或存储过程中使用 FOR XML 子句。在性能测试中，使用 FOR XML 只比返回 DataSet 稍微快一点。
  • 检索 DataSet 并将其转换为 XML 流或以 XML 流的格式写出。这种方法会带来创建 DataSet 的系统开销和额外的转换开销（如果执行转换）。
  • 使用输出参数或数据读取器构建一个 XML 文档。数据读取器是从数据库检索多个行的最快方法，但与构建 XML 相关联的过程可能会减弱这种性能优势。

有关详细信息或性能方面的考虑，请参阅 Performance Comparison:Data Access Techniques。

将业务实体表示为 XML 的优点如下：

• 标准支持。XML 是 World Wide Web Consortium (W3C) 的标准数据表示格式。有关此标准的详细信息，请参阅 http://www.w3.org/xml。
• 灵活性。XML 能够表示信息的层次结构和集合。有关详细信息，请参阅附录中的如何使用 XML 表示数据的集合和层次结构。
• 互操作性。在所有平台上，XML 都是与外部各方及贸易伙伴交换信息的理想选择。如果 XML 数据将由 ASP.NET 应用程序或 Windows 窗体应用程序使用，则还可以把这些 XML 数据装载到一个 DataSet 中，以利用 DataSet 提供的数据绑定支持。

将业务实体表示为 XML 的缺点如下：

• 类型保真。XML 不支持类型保真。然而，对于简单的数据分类可以使用 XSD 架构。
• 验证 XML。要验证 XML，可以手动分析代码，或者使用 XSD 架构。但这两种方法都比较慢。有关如何使用 XSD 架构验证 XML 的示例，请参阅如何使用 XSD 架构验证 XML。
• 显示 XML。您不能将 XML 数据自动显示在用户界面上。可以编写一个 XSLT 样式表将数据转换为 DataSet；但样式表的编写比较麻烦。另一种方法是通过样式表将 XML 转换为 HTML 等可显示格式。有关详细信息，请参阅附录中的如何在 .NET 应用程序中编程应用样式表。
• 分析 XML。要分析 XML，可以使用文档对象模型 (DOM) 或 Microsoft .NET Framework 类库提供的 XmlReader 类。XmlReader 提供对 XML 数据的快速只读的、仅向前的访问，而 DOM 可以提供随机读/写访问，因此更灵活。然而，使用 DOM 分析 XML 文档的速度较慢；您必须创建一个 XmlDocument 实例（或另一个 XML 分析器类）并把整个 XML 文件装载到内存中。
• 排序 XML。您不能自动排序 XML 数据，而应使用以下技术之一：
  • 按预先排好的顺序提供数据。这种方法不支持在调用应用程序中动态重新排序数据。
  • 应用 XSLT 样式表动态排序数据。如果需要，可以使用 DOM 在运行时改变 XSLT 样式表中的排序条件。
  • 将 XML 数据转换为 DataSet，并使用 DataView 对象排序和搜索数据元素。
• 使用专用字段。您不能选择隐藏信息。

将业务实体表示为通用 DataSet

通用 DataSet 是 DataSet 类的实例，它是在 ADO.NET 的 System.Data 命名空间中定义的。DataSet 对象包含一个或多个 DataTable 对象，用以表示数据访问逻辑组件从数据库检索到的信息。

图 7 所示为用于 Product 业务实体的通用 DataSet 对象。该 DataSet 对象具有一个 DataTable，用于保存产品信息。该 DataTable 具有一个 UniqueConstraint 对象，用于将 ProductID 列标记为主键。DataTable 和 UniqueConstraint 对象是在数据访问逻辑组件中创建该 DataSet 时创建的。

图 7：用于 Product 业务实体的通用 DataSet

图 8 所示为用于 Order 业务实体的通用 DataSet 对象。此 DataSet 对象具有两个 DataTable 对象，分别保存订单信息和订单详细信息。每个 DataTable 具有一个对应的 UniqueConstraint 对象，用于标识表中的主键。此外，该 DataSet 还有一个 Relation 对象，用于将订单详细信息与订单相关联。

图 8：用于 Order 业务实体的通用 DataSet

以下代码显示了如何从数据访问逻辑组件检索通用 DataSet ，然后将该 DataSet 绑定到 DataGrid 控件，再将该 DataSet 传递到数据访问逻辑组件以保存对数据所做的更改：

// 创建 ProductDALC 对象
ProductDALC dalcProduct = new ProductDALC();

// 对 ProductDALC 调用一个方法以获取一个包含全部产品信息的 DataSet
DataSet dsProducts = dalcProduct.GetProducts();

// 在客户端中使用 DataSet。 例如，把该 DataSet 绑定到用户界面控件
dataGrid1.DataSource = dsProducts.Tables[0].DefaultView;
dataGrid1.DataBind();

// 然后，把更新后的 DataSet 传递给 ProductDALC，将更改
// 保存到数据库
dalcProduct.UpdateProducts(dsProducts);

您还可以在运行时查询和修改 DataSet 中的表、约束及关系。有关详细信息，请参阅 Creating and Using DataSets。

将业务实体表示为通用 DataSet 的优点如下：

• 灵活性。DataSet 可以包含数据的集合，能够表示复杂的数据关系。
• 序列化。在层间传递时，DataSet 本身支持序列化。
• 数据绑定。可以把 DataSet 绑定到 ASP.NET 应用程序和 Windows 窗体应用程序的任意用户界面控件。
• 排序与过滤。可以使用 DataView 对象排序和过滤 DataSet。应用程序可以为同一个 DataSet 创建多个 DataView 对象，以便用不同方式查看数据。
• 与 XML 的互换性。可以用 XML 格式读写 DataSet。这种方法在远程和脱机应用程序中很有用，它可以用 XML 格式接收 DataSet，然后在本地重新创建该 DataSet 对象。应用程序在与数据库断开连接后，还可以将 DataSet 保持为 XML 格式。
• 元数据的可用性。可以用 XSD 架构的形式为 DataSet 提供完整的元数据。还可以使用 DataSet、DataTable、DataColumn、Constraint 和 Relation 类中的方法以编程方式为 DataSet 获取元数据。
• 开放式并发。在更新数据时，可以配合使用数据适配器与 DataSet 以方便地执行开放式并发检查。
• 可扩展性。如果修改了数据库架构，则适当情况下数据访问逻辑组件中的方法可以创建包含修改后的 DataTable 和 DataRelation 对象的 DataSet。数据访问逻辑组件方法签名并不改变。可以将调用应用程序修改为使用该 DataSet 中的这些新元素。

将业务实体表示为通用 DataSet 的缺点如下：

• 客户端代码必须通过 DataSet 中的集合访问数据。要访问 DataSet 中的表，客户端代码必须使用整数索引生成器或字符串索引生成器来索引 DataTable 集合。要访问特定列，必须使用列编号或列名称索引 DataColumn 集合。以下示例显示了如何访问 Products 表中第一行的 ProductName 列：

// 获取所调用的名为 dsProducts 的 DataSet 的第一行的 
// 产品名称。 注意，该集合是基于零的。
String str = (String)dsProducts.Tables["Products"].Rows[0]["ProductName"];

实例化和封送处理的成本很高。DataSet 需要创建多个子对象（DataTable、DataRow 和 DataColumn），这意味着在实例化和封送处理时，DataSet 会比 XML 字符串或自定义实体组件花费更长的时间。随着数据量的增大，创建 DataSet 内部结构的系统开销将明显少于将数据填充到 DataSet 中所需的开销，因此 DataSet 的相对性能会随之提高。 专用字段。您不能选择隐藏信息。

将业务实体表示为有类型的 DataSet

有类型的 DataSet 是包含具有严格类型的方法、属性和类型定义以公开 DataSet 中的数据和元数据的类。有关如何创建有类型的 DataSet 的示例，请参阅附录中的如何创建有类型的 DataSet。

下面列出了有类型的 DataSet 与通用 DataSet 相比的优缺点。注意，有类型的 DataSet 的实例化和封送处理性能与通用 DataSet 基本相同。

将业务实体表示为有类型的 DataSet 的优点如下：

• 代码易读。要访问有类型的 DataSet 中的表和列，可以使用有类型的方法和属性，如以下代码所示：

// 获取所调用的名为 dsProducts 的有类型的 DataSet 的第一行的
// 产品名称。 注意，该集合是基于零的。
String str = dsProducts.Products[0].ProductName;

在本示例中，dsProducts 是有类型的 DataSet 的一个实例。该 DataSet 有一个 DataTable，它由一个命名为 Products 的属性公开。该 DataTable 中的列由 ProductName 等属性公开，后者返回列的相应数据类型（而不仅仅返回对象）。

有类型的方法和属性的提供使得使用有类型的 DataSet 比使用通用 DataSet 更方便。使用有类型的 DataSet 时，IntelliSense 将可用。

编译时类型检查。无效的表名称和列名称将在编译时而不是在运行时检测。

将业务实体表示为有类型的 DataSet 的缺点如下：

• 部署。必须将包含有类型的 DataSet 类的程序集部署到使用业务实体的所有层。
• 支持企业服务 (COM+) 调用程序。如果有类型的 DataSet 将由 COM+ 客户端使用，则必须为包含该有类型的 DataSet 类的程序集提供一个严格名称，并且必须在客户端计算机上注册。通常，该程序集安装在全局程序集缓存中。这些也是自定义实体类所要求的步骤，如本文后面所述。
• 可扩展性问题。如果修改了数据库架构，则可能需要重新生成有类型的 DataSet 类以支持新架构。重新生成过程将不会保留在有类型的 DataSet 类中实现的任何自定义代码。必须将包含有类型的 DataSet 类的程序集重新部署到所有客户端应用程序中。
• 实例化。您不能使用 new 运算符来实例化类型。
• 继承。有类型的 DataSet 必须从 DataSet 类继承，这会禁止使用任何其他基本类。

定义自定义业务实体组件

表示业务实体的自定义类通常包含以下成员：

• 用于在本地缓存业务实体的数据的专用字段。这些字段在数据访问逻辑组件从数据库检索数据时保存数据库数据的一个快照。
• 用于访问实体的状态和访问实体内数据的子集及层次结构的公共属性。这些属性的名称可以与数据库的列名称相同，但这并不是一个绝对要求。可以根据您的应用程序的需要选择属性名，而不必使用数据库中的名称。
• 用以使用实体组件中的数据执行本地化处理的方法和属性。
• 用以通知实体组件内部状态变化的事件。

图 9 所示为使用自定义实体类的方法。注意，实体类并不知道数据访问逻辑组件或基础数据库；所有数据库访问都由数据访问逻辑组件执行，以集中数据访问策略和业务逻辑。此外，在层间传递业务实体数据的方式与表示业务实体的格式也没有直接关系；例如，可以在本地将业务实体表示为对象，而用另一种方法（如标量值或 XML）将业务实体数据传递到其他层。

图 9：自定义业务实体组件的作用（单击缩略图以查看大图像）

 

定义自定义业务实体组件的建议

在实现自定义实体组件时，请考虑以下建议：

• 选择使用结构还是使用类。对于不包含分层数据或集合的简单业务实体，可以考虑定义一个结构来表示业务实体。对于复杂的业务实体或要求继承的业务实体，可将实体定义为类。有关结构和类这两种类型的比较，请参阅 Structures and Classes。
• 表示业务实体的状态。对于数字、字符串等简单值，可以使用等价的 .NET 数据类型来定义字段。有关说明如何定义自定义实体的代码示例，请参阅附录中的如何定义业务实体组件。
• 表示自定义业务实体组件中的子集合和层次结构。表示自定义实体中的数据的子集合和层次结构的方法有两种：
  • .NET 集合（例如 ArrayList）。.NET 集合类为大小可调的集合提供了一个方便的编程模型，还为将数据绑定到用户界面控件提供了内置的支持。
  • DataSet。DataSet 适合于存储来自关系数据库或 XML 文件的数据的集合和层次结构。此外，如果需要过滤、排序或绑定子集合，也应首选 DataSet。

    有关说明如何表示自定义实体中数据的集合和层次结构的代码示例，请参阅附录中的如何表示自定义实体中数据的集合和层次结构。

• 支持用户界面客户端的数据绑定。如果自定义实体将要由用户界面使用并且希望利用自动数据绑定，可能需要在自定义实体中实现数据绑定。请考虑以下方案：
  • Windows 窗体中的数据绑定。您可以将实体实例的数据绑定到控件而不必在自定义实体中实现数据绑定接口。也可以绑定实体的数组或 .NET 集合。
  • Web 窗体中的数据绑定。如果不实现 IBindingList 接口，则不能将实体实例的数据绑定到 Web 窗体中的控件。然而，如果只想绑定集合，则可以使用数组或 .NET 集合而不必在自定义实体中实现 IBindingList 接口。

    有关说明如何将自定义实体绑定到用户界面控件的代码示例，请参阅附录中的如何将业务实体组件绑定到用户界面控件。

• 公开内部数据更改的事件。公开事件可以获得丰富的客户端用户界面设计，因为它使得无论数据显示在哪里都可以对其进行刷新。事件应当只针对内部状态，而不是针对服务器上的数据更改。有关说明如何公开自定义实体类中的事件的代码示例，请参阅附录中的如何公开业务实体组件中的事件。
• 使业务实体可序列化。使业务实体可序列化可以将业务实体的状态保持在中间状态而不进行数据库交互。这样可以方便脱机应用程序的开发和复杂用户界面过程的设计，即在完成前不会影响业务数据。序列化有两种类型：
  • 使用 XmlSerializer 类进行 XML 序列化。如果只需要把公共字段和公共读/写属性序列化为 XML，则可以使用 XML 序列化。注意，如果从 Web 服务返回业务实体数据，对象将通过 XML 序列化自动序列化为 XML。

    您可以对业务实体执行 XML 序列化而无需在实体中实现任何附加代码。然而，只有对象中的公共字段和公共读/写属性被序列化为 XML。专用字段、索引生成器、专用属性、只读属性及对象图不会被序列化。您可以使用自定义实体中的属性控制结果 XML。有关将自定义实体组件序列化为 XML 格式的详细信息，请参阅附录中的如何将业务实体组件序列化为 XML 格式。

  • 使用 BinaryFormatter 或 SoapFormatter 类进行格式序列化。如果需要序列化对象的所有公共字段、专用字段及对象图，或者需要与远程服务器之间传递实体组件，则可以使用格式序列化。

    格式类将序列化对象的所有公共和专用字段及属性。BinaryFormatter 将对象序列化为二进制格式，SoapFormatter 将对象序列化为 SOAP 格式。使用 BinaryFormatter 的序列化比使用 SoapFormatter 的序列化速度要快。要使用任何一个格式类，都必须将实体类标记为 [Serializable] 属性。如果需要显式控制序列化格式，您的类还必须实现 ISerializable 接口。有关如何使用格式序列化的详细信息，请参阅附录中的如何将业务实体组件序列化为二进制格式及如何将业务实体组件序列化为 SOAP 格式。

  注意：还原序列化某个对象时，不会调用默认的构造函数。对还原序列化添加这项约束，是出于性能方面的考虑。

定义自定义实体的优点如下：

• 代码易读。要访问自定义实体类中的数据，可以使用有类型的方法和属性，如以下代码所示：

  // 创建一个 ProductDALC 对象
      ProductDALC dalcProduct = new ProductDALC();
      // 使用该 ProductDALC 对象创建和填充一个 ProductEntity 对象。
      // 此代码假设 ProductDALC 类有一个名为 GetProduct 的方法，
      // 该方法使用 Product ID 作参数（本例中为 21），并返回一个
      // 包含该产品的所有数据的 ProductEntity 对象。
      ProductEntity aProduct = dalcProduct.GetProduct(21);
      // 更改该产品的产品名称
      aProduct.ProductName = "Roasted Coffee Beans";
      

  在上述示例中，产品是一个名为 ProductEntity 的自定义实体类的一个实例。ProductDALC 类有一个名为 GetProduct 的方法，后者创建一个 ProductEntity 对象，将某个特定产品的数据填充到该对象，然后返回 ProductEntity 对象。调用应用程序可以使用 ProductName 等属性访问 ProductEntity 对象中的数据，并且可以调用方法以操作该对象。

• 封装。自定义实体可以包含方法以封装简单的业务规则。这些方法操作缓存在实体组件中的业务实体数据，而不是访问数据库中的实时数据。请考虑以下示例：

  // 调用一个在 ProductEntity 类中定义的方法。
      aProduct.IncreaseUnitPriceBy(1.50);
      

  在上述示例中，调用应用程序对 ProductEntity 对象调用一个名为 IncreaseUnitPriceBy 的方法。在调用应用程序对 ProductDALC 对象调用相应方法，从而将 ProductEntity 对象保存到数据库之前，这一更改并不是永久性的。

• 构建复杂系统的模型。在构建复杂域问题（在不同业务实体之间存在很多交互）的模型时，可以定义自定义实体类，从而将复杂性隐藏在经过很好定义的类接口的后面。
• 本地化验证。自定义实体类可以在其属性存取器中执行简单的验证测试以检测无效的业务实体数据。有关详细信息，请参阅如何在业务实体组件的属性存取器中验证数据。
• 专用字段。您可以隐藏不希望向调用程序公开的信息。

定义自定义实体的缺点如下：

• 业务实体集合。自定义实体表示的是单个业务实体，而不是一个业务实体集合。要保存多个业务实体，调用应用程序必须创建一个数组或一个 .NET 集合。
• 序列化。您必须在自定义实体中实现自己的序列化机制。可以使用属性来控制实体组件的序列化方式，也可以通过实现 ISerializable 接口来控制自己的序列化。
• 表示业务实体中的复杂关系和层次结构。您必须在业务实体组件中实现自己的关系和层次结构表示机制。如前面所述，DataSet 通常是实现这一目的的最简单方式。
• 搜索和排序数据。您必须定义自己的机制来支持实体的搜索和排序。例如，可以通过实现 IComparable 接口以便将实体组件保存在一个 SortedList 集合或 Hashtable 集合中。
• 部署。您必须在所有物理层部署包含自定义实体的程序集。
• 支持企业服务 (COM+) 客户端。如果一个自定义实体将由 COM+ 客户端使用，则必须为包含该实体的程序集提供一个严格名称，并且必须在客户端计算机上注册。通常，该程序集安装在全局程序集缓存中。
• 可扩展性问题。如果修改了数据库架构，则可能需要修改自定义实体类并重新部署程序集。

定义带有 CRUD 行为的自定义业务实体组件

在定义一个自定义实体时，可以提供方法以完全封装对基础数据访问逻辑组件的 CRUD 操作。这是比较传统的面向对象的方法，可能适用于复杂的对象域。客户端应用程序不再直接访问数据访问逻辑组件类，而是创建一个实体组件并对该实体组件调用 CRUD 方法。这些方法将调用基础的数据访问逻辑组件。

图 10 所示为带有 CRUD 行为的自定义实体类的作用。

图 10：带有 CRUD 行为的自定义业务实体组件的作用（单击缩略图以查看大图像）

 

定义带有 CRUD 行为的自定义实体类的优点如下：

• 封装。自定义实体可以封装由基础数据访问逻辑组件定义的操作。
• 与调用程序的接口。调用程序必须只处理一个接口来保持业务实体数据。不必直接访问数据访问逻辑组件。
• 专用字段。您可以隐藏不希望向调用程序公开的信息。

定义带有 CRUD 行为的自定义实体类的缺点如下：

• 处理业务实体集合。自定义实体中的方法属于单个业务实体实例。要支持业务实体集合，可以定义静态方法以读取或返回一个数组或一个实体组件集合。
• 开发时间长。传统的面向对象方法通常比使用现有对象（如 DataSet）需要更多的设计和开发工作。

表示数据和在层间传递数据的建议

在您的应用程序中表示数据的方式以及在层间传递数据的方式不一定要相同。然而，一套一致而有限的格式能够降低对附加转换层的需要，从而提高性能并方便维护。

应根据自己特定的应用程序要求和操作数据的方式选择数据格式。这里并没有一个通用的表示方式，特别是由于当今的许多应用程序都需要支持多个调用程序。然而，我们还是建议遵循以下一般原则：

• 如果您的应用程序主要处理集合并需要排序、搜索和数据绑定等功能，则建议采用 DataSet。但如果应用程序处理实例数据，则采用标量值的效果会更好。
• 如果您的应用程序主要处理实例数据，则自定义业务实体组件可能是最佳选择，因为它们可以消除一个 DataSet 表示一行时的系统开销。
• 大多数情况下，应把应用程序设计为使用 XML 文档、DataSet 等以数据为中心的格式。可以利用 DataSet 提供的灵活性及固有功能来更方便地支持多个客户端、减少自定义代码的数量并使用为大多数开发人员所熟知的编程 API。虽然以面向对象的方式操作数据有很多好处，但自定义编码复杂的业务实体会使开发和维护成本随所提供功能的数量成比例增加。

转载于:https://www.cnblogs.com/feiren1421/archive/2006/10/05/521450.html