.net数据设计与应用

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

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

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

• 固有功能。DataSet 提供了内置功能，可以处理开放式并发（以及数据适配器）并支持复杂的数据结构。此外，有类型的 DataSet 还提供了数据验证支持。
  
  
• 业务实体集合。DataSet 是为处理复杂的关系集合而设计的，因此不需要再编写自定义代码来实现这一功能。
  
  
• 维护。更改架构不会影响方法签名。然而，如果使用的有类型的 DataSet 和程序集具有严格名称，则必须按照新版本重新编译数据访问逻辑组件类，或在全局程序集缓存中使用发布者策略，或在配置文件中定义一个 <bindingRedirect> 元素。
  
  
• 序列化。DataSet 本身支持 XML 序列化，并且可以跨层序列化。

这种方法的缺点如下：

• 性能。实例化和封送处理 DataSet 会增加运行时负担。
  
  
• 表示单个业务实体。DataSet 是为处理一组数据而设计的。如果您的应用程序主要处理实例数据，则标量值或自定义实体是更好的方法，后者不会影响性能。

将自定义业务实体组件作为输入和输出传递

这种方法的优点如下：

• 维护。更改架构不会影响数据访问逻辑组件方法签名。然而，如果业务实体组件包含在严格命名的程序集中，就会出现与有类型的 DataSet 同样的问题。
  
  
• 业务实体集合。可以将自定义业务实体组件的数组和集合传入和传出方法。

这种方法的缺点如下：

• 支持开放式并发。要方便地支持开放式并发，必须在数据库中定义时间戳列并将其作为实例数据的一部分。
  
  
• 集成限制。当使用自定义业务实体组件作为数据访问逻辑组件的输入时，调用程序必须知道业务实体的类型，而这会限制不使用 .NET 的调用程序的集成。然而，如果调用程序使用自定义业务实体组件作为数据访问逻辑组件的输出，则上述问题并不会限制集成。例如，Web 方法可以返回从数据访问逻辑组件返回的自定义业务实体组件，并使用 XML 序列化自动将该业务实体组件序列化为 XML。

将数据读取器作为输出返回

这种方法的优点如下：

• 性能。当需要快速呈现数据时，这种方法具有性能优势，并且可以使用表示层代码部署数据访问逻辑组件。

这种方法的缺点如下：

• 远程。建议不要在远程方案中使用数据读取器，因为它可能会使客户端应用程序与数据库保持长时间的连接。

配合使用数据访问逻辑组件与存储过程

可以使用存储过程执行数据访问逻辑组件支持的许多数据访问任务。

优点

• 存储过程通常可以改善性能，因为数据库能够优化存储过程使用的数据访问计划并为以后的重新使用缓存该计划。
  
  
• 可以在数据库内分别设置各个存储过程的安全保护。管理员可以授予客户端执行某个存储过程的权限，而不授予任何基础表访问权限。
  
  
• 存储过程可以简化维护，因为修改存储过程通常比修改所部署的组件中的硬编码 SQL 语句要容易。然而，随着在存储过程中实现的业务逻辑的增多，上述优势会逐渐减弱。
  
  
• 存储过程增大了从基础数据库架构进行抽象的程度。存储过程的客户端与存储过程的实现细节和基础架构是彼此分离的。
  
  
• 存储过程会降低网络流量。应用程序可以按批执行 SQL 语句而不必发出多个 SQL 请求。
  
  
• 尽管存储过程具有上述优点，但仍有某些情况不适合使用存储过程。

缺点

• 如果逻辑全部在存储过程中实现，那么涉及广泛业务逻辑和处理的应用程序可能会给服务器带来过重负荷。这类处理包括数据传输、数据遍历、数据转换和大计算量操作。应把这类处理移到业务过程或数据访问逻辑组件中，与数据库服务器相比，它们具有更好的可缩放性。
  
  
• 不要把所有业务逻辑都放在存储过程中。如果必须在 T - SQL 中修改业务逻辑，应用程序的维护和灵活性将成为问题。例如，支持多个 RDBMS 的 ISV 应用程序不应当分别为每个系统维护存储过程。
  
  
• 通常，存储过程的编写与维护是一项专门技能，并非所有开发人员都能够掌握。这会造成项目开发计划的瓶颈。

配合使用数据访问逻辑组件与存储过程的建议

配合使用数据访问逻辑组件与存储过程时，请考虑以下建议：

• 公开存储过程。数据访问逻辑组件应当是向存储过程名称、参数、表、字段等数据库架构信息公开的仅有组件。业务实体实现应不需要知道或依赖于数据库架构。
  
  
• 使存储过程与数据访问逻辑组件相关联。每个存储过程只应被一个数据访问逻辑组件调用，并应与调用它的数据访问逻辑组件相关联。例如，假设一个客户向一个零售商订货。您可以编写一个名为 OrderInsert 的存储过程，用于在数据库中创建订单。在您的应用程序中，必须确定是从 Customer 数据访问逻辑组件还是从 Order 数据访问逻辑组件调用该存储过程。Order 数据访问逻辑组件处理所有与订单相关的任务，而 Customer 数据访问逻辑组件处理客户姓名、地址等客户信息，因此最好使用前者。
  
  
• 命名存储过程。为要使用的数据访问逻辑组件定义存储过程时，所选择的存储过程名称应当强调与之相关的数据访问逻辑组件。这种命名方法有助于识别哪个组件调用哪个存储过程，并为在 SQL 企业管理器中逻辑分组存储过程提供了一种方法。例如，可以事先编写名为 CustomerInsert、CustomerUpdate、CustomerGetByCustomerID、CustomerDelete 的存储过程供 Customer 数据访问逻辑组件使用，然后提供 CustomerGetAllInRegion 等更具体的存储过程以支持您的应用程序的业务功能。
  
  注意：不要在存储过程名称前面使用前缀 sp_，这会降低性能。当调用一个以 sp_ 开头的存储过程时，SQL Server 始终会先检查 master 数据库，即使该存储过程已由数据库名称进行限定。
  
  
• 解决安全性问题。如果接受用户输入以动态执行查询，请不要通过没有使用参数的连接值来创建字符串。如果使用 sp_execute 执行结果字符串，或者不使用 sp_executesql 参数支持，则还应避免在存储过程中使用字符串连接。

管理锁定和并发

某些应用程序在更新数据库数据时采用“后进有效”(Last in Wins) 法。使用“后进有效”法更新数据库时不会将更新与原始记录相比较，因此可能会覆盖掉自上次刷新记录以来其他用户所做的所有更改。然而，有时应用程序却需要在执行更新之前确定数据自最初读取以来是否被更改。

数据访问逻辑组件可以实现管理锁定和并发的代码。管理锁定和并发的方法有两种：

• 保守式并发。为进行更新而读取某行数据的用户可以在数据源中对该行设置一个锁定。在该用户解除锁定之前，其他任何用户都不能更改该行。
  
  
• 开放式并发。用户在读取某行数据时不锁定该行。其他用户可以在同一时间自由访问该行。当用户要更新某行数据时，应用程序必须确定自该行被读取以来其他用户是否进行过更改。尝试更新已经过更改的记录会导致并发冲突。

// 创建 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 中的表、约束及关系。

将业务实体表示为通用 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 时不支持 IntelliSense。
  
  
• 实例化和封送处理的成本很高。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）将业务实体数据传递到其他层。

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

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

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

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

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

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

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

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

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

事务处理

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

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

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

实现事务处理

在大多数环境中，事务处理的根本是业务过程而不是数据访问逻辑组件或业务实体组件。这是因为业务过程一般要求事务处理跨多个业务实体而不仅仅是单个业务实体。

然而，也可能出现在没有高层次业务过程的帮助下对单个业务实体执行事务性操作的情况。例如，要把一个新客户添加到前面讨论的数据库中，您必须执行以下操作：

• 在 Customer 表中插入新的一行。
  
  
• 在 Address 表中插入新的一行或多行。

只有这两个操作都成功后客户才会被添加到数据库中。如果 Customer 业务实体不会成为启动该事务处理的更大的业务过程的一部分，则应在 Customer 业务实体中使用手动事务处理。手动事务处理不要求与 Microsoft 分布式事务处理协调器 (DTC) 之间进行任何进程间通信，因此比自动事务处理要快得多。


图11 所示为确定使用手动事务处理还是自动事务处理的方法。由于 COM+ 事务处理的系统开销，建议将事务处理放到数据库中并在存储过程中控制事务性行为（如果可能）。

注意：如果从基于 ASP.NET 的客户端进行调用，并且没有用于启动事务处理的业务过程，则您可能会从 ASP.NET 代码中启动该事务处理。这种设计并不好；您决不能从基于 ASP.NET 的客户端启动事务处理，而应将数据的展示与业务过程相分离。此外，由于网络滞后等问题还会导致性能问题，因为这是要实际部署在其他层上的最常见的层。

在数据访问逻辑组件中使用手动事务处理的建议

在数据访问逻辑组件中实现手动事务处理时，请考虑以下建议：

• 尽可能在存储过程中执行处理。使用 Transact-SQL 语句 BEGIN TRANSACTION、END TRANSACTION 和 ROLLBACK TRANSACTION 控制事务处理。
  
  
• 如果没有使用存储过程，并且也不会从业务过程中调用数据访问逻辑组件，则可以使用 ADO.NET 来编程控制事务处理。

在数据访问逻辑组件中使用自动事务处理的建议

虽然 COM+ 事务处理会带来一些系统开销，但自动事务处理能够提供比手动事务处理更简单的编程模式，而且在事务处理跨多个分布式数据源（与 DTC 一起工作）时必须使用自动事务处理。在数据访问逻辑组件中实现自动事务处理时，请考虑以下建议：

• 数据访问逻辑组件必须是从 System.EnterpriseServices 命名空间中的 ServicedComponent 类继承而来。注意，使用 COM+ 服务注册的所有程序集都必须具有严格的名称。
  
  
• 使用 Transaction(TransactionOption.Supported) 属性注释数据访问逻辑组件，以便可以在同一组件中执行读写操作。与 Transaction(TransactionOption.Required) 不同，此选项在不需要事务处理时避免了不必要的系统开销，而前者始终会要求事务处理。

以下代码示例显示了如何在数据访问逻辑组件类中支持自动事务处理：

using System.EnterpriseServices;

[Transaction(TransactionOption.Supported)]
public class CustomerDALC : ServicedComponent
{
  ...
}

如果使用自动事务处理，则数据访问逻辑组件应在事务处理中表明操作是否成功。如果要隐式表明，应使用 AutoComplete 属性注释您的方法并在操作失败时发出一个异常。如果要显式表明，应对 ContextUtil 类调用 SetComplete 或 SetAbort 方法。

在业务实体组件中使用自动事务处理

在实现带有行为的自定义业务实体组件时，可以使用自动事务处理来指定这些对象的事务性行为。有关使用自动事务处理指定业务实体组件事务性行为的建议与前述有关在数据访问逻辑组件中实现自动事务处理的建议相同。

注意：如果业务实体组件不包含任何要求其在事务处理中表明是否成功的业务逻辑，则它可以忽略事务处理环境。自定义业务实体组件不需要从 ServicedComponent 继承；事务处理环境仍将继续其流程，但实体组件将忽略事务处理环境。

验证

您可以在应用程序的许多层上进行数据验证。各层适用不同的验证类型：

• 在提交数据之前，客户端应用程序可以在本地验证业务实体数据。
  
  
• 使用 XSD 架构接收业务文档时，业务过程可以验证这些文档。
  
  
• 数据访问逻辑组件和存储过程可以验证数据，以确保引用的完整性并强制遵循约束以及重要的业务规则。

常用验证有两种：

• 即时点验证。这是在一个特定时点执行的验证。例如，在接收 XML 文档时由业务过程对其进行验证。
  
  
• 连续验证。这是在应用程序的许多不同层次上持续进行的一种验证。连续验证的示例包括：
  
  
  • 用户界面可以指定字段的最大长度以防止用户输入过长的字符串。
    
    
  • DataSet 可以指定数据列的最大长度。
    
    
  • 自定义业务实体组件可以对实体数据执行范围检查、长度检查、非空检查以及其他简单测试。
    
    
  • 数据访问逻辑组件、存储过程和数据库本身可以执行类似的测试，以便在将数据保存到数据库之前确保其有效性。

有时，您可能希望实现额外的聚合过程或转换过程。这种方法在验证和转换经常变化时可能很有用，但会损失性能。例如，如果一个 ISV 想要使用相同的组件支持数据库架构的两个版本，则您可以创建一个单独的组件来执行两个数据库架构版本之间的验证和转换。

如何使用 XSD 架构验证 XML

要使用 XSD 架构验证 XML 文档，请执行以下步骤：

1. 创建一个 XmlValidatingReader 对象作为 XmlTextReader 对象的包装，如以下代码所示：
   
   

   ' 创建 XmlValidatingReader 对象，以读取和验证 Product.xml XmlTextReader tr = new XmlTextReader("Product.xml"); XmlValidatingReader vr = new XmlValidatingReader(tr);

   
   
   
2. 通过使用 ValidationType 枚举指定所需的验证类型。.NET Framework 支持三种类型的 XML 验证：
   
   文档类型定义 (DTD)；指定 ValidationType.DTD
   
   Microsoft XML 精简数据 (XDR) 架构；指定 ValidationType.XDR
   
   W3C 标准 XSD 架构；指定 ValidationType.Schema
   
   以下代码显示了 ValidationType 枚举的使用：
   
   

   vr.ValidationType = ValidationType.Schema; ' 指定 XSD 架构验证

   
   
   
3. 注册一个验证事件处理程序方法，如以下代码所示：
   
   

   vr.ValidationEventHandler += new ValidationEventHandler(MyHandlerMethod);

   
   
   
4. 提供一个验证事件处理程序方法的实现，如以下代码所示：
   
   

   public void MyHandlerMethod(object sender, ValidationEventArgs e) { Console.WriteLine("验证错误:" + e.Message); }

   
   
   
5. 读取和验证文档，如以下代码所示。验证错误将被验证事件处理程序方法拾取。
   
   

   try { while (vr.Read()) { // 适当处理 XML 数据... } } catch (XmlException ex) { Console.WriteLine("XmlException: " + ex.Message); } vr.Close();

如何在业务实体组件的属性存取器中验证数据

以下代码片段显示了如何在自定义实体的属性存取器中进行简单验证。如果验证测试失败，您可以发出一个异常以显示问题的性质。也可以在属性存取器集合中使用正则表达式来验证特定的数据和格式。

public class ProductDALC
{
 ...
  public short ReorderLevel
  {
    get { return reorderLevel; }
  }
  set
  {
    if (value < 0)
    {
      throw new ArgumentOutOfRangeException("ReorderLevel 不能为负数。");
    }
    reorderLevel = value;
  }

  // 加上 ProductDALC 类中的其他成员...
}

异常管理

当 .NET 应用程序出现错误时，通常的建议是发出异常而不是从方法返回错误值。这一建议暗示了您编写数据访问逻辑组件和业务实体组件的方式。异常大体上有两种：

技术异常，它包括：

• ADO.NET
  
  
• 数据库连接
  
  
• 资源（如数据库、网络共享、消息队列等）不可用
  
  业务逻辑异常，它包括：
  
  
• 验证错误
  
  
• 实现业务逻辑的存储过程中的错误
  
  在数据访问逻辑组件中管理异常的建议
  
  数据访问逻辑组件应该传播异常，并且仅在能够使客户端对异常的管理更加容易时才包装异常类型。将异常包装为两种主要异常类型（技术异常和业务异常）有利于各种可能的调用程序的异常处理结构和异常发布逻辑。
  
  您的应用程序应当发布异常信息。可以将技术异常发布到一个由系统管理员或 Windows 管理规范 (WMI) 监视工具（如 Microsoft Operations Manager）监视的日志中；将业务异常发布到一个特定的应用程序日志中。通常，应允许从数据访问逻辑组件传播异常并允许由调用程序发布异常，以便您了解异常的整个环境。
  
  以下示例说明了这些建议：
  
  

  public class CustomerDALC { public void UpdateCustomer(Dataset aCustomer) { try { // 更新数据库中的客户... } catch (SqlException se) { // 捕获并包装异常，然后重新发出 throw new DataAccessException("数据库不可用", se); } finally { // 清除代码 } } }

  
  
  在业务实体组件中管理异常的建议
  
  业务实体组件应当向调用程序传播异常。在业务实体组件执行验证或者当调用程序试图执行某一操作而未提供该操作所需的数据时，业务实体组件也可以产生异常。
  
  以下示例显示了业务实体组件如何产生异常。在此示例中，如果没有提供客户的名字，Update 方法将发出一个异常：
  
  

  public class CustomerEntity { public void Update() { // 检查用户已提供了所需数据。这里是客户 // 的名字 if (FirstName == "" ) { // 发出一个已定义的新的应用程序异常 throw new MyArgumentException("您必须提供名字。"); } ... } }

  
  
  有关在 .NET 应用程序中处理异常的详细信息，请参阅 Exception Management in .NET。可以从 Exception Management Application Block 提供的 ApplicationException 类或 BaseApplicationException 类中继承自定义技术异常和自定义业务异常。

授权与安全性

学习向 Microsoft .NET 应用程序公开数据的最佳方式，以及如何实现一个有效的策略以便在分布式应用程序的层间传递数据。（本文包含一些指向英文站点的链接。）

本节说明如何将安全性应用于数据访问逻辑组件和业务实体组件。.NET 公共语言运行库使用权限对象实现其对托

文章来源于领测软件测试网 https://www.ltesting.net/

TAG: net 设计 数据 应用 与