数据层组件设计与数据传递 (6)

定义自定义业务实体组件

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

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

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

图 9：自定义业务实体组件的作用

 

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

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

• 选择使用结构还是使用类。对于不包含分层数据或集合的简单业务实体，可以考虑定义一个结构来表示业务实体。对于复杂的业务实体或要求继承的业务实体，可将实体定义为类。
• 表示业务实体的状态。对于数字、字符串等简单值，可以使用等价的 .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。

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

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

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

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

• 代码易读。要访问自定义实体类中的数据，可以使用有类型的方法和属性，如以下代码所示： // 创建一个 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。虽然以面向对象的方式操作数据有很多好处，但自定义编码复杂的业务实体会使开发和维护成本随所提供功能的数量成比例增加。

　　事务处理

　　当今的大多数应用程序都需要支持事务处理以保持系统数据的完整性。事务处理的管理方法有多种，但每种方法都可归于以下两种基本编程模型之一：

• 手动事务处理。直接在组件代码或存储过程中编写使用 ADO.NET 或 Transact-SQL 事务处理支持功能的代码。
• 自动事务处理。使用企业服务 （COM+） 为 .NET 类添加声明属性以便在运行时指定对象的事务性要求。使用这种模型可以方便地配置多个组件以执行同一事务中的工作。

　　本节提供一些指导原则和建议，帮助您在数据访问逻辑组件和业务实体组件中实现事务处理支持。