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

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

• 花些时间来分析您的应用程序的逻辑业务实体并为之建立模型，不要为每个表定义一个单独的业务实体。建立应用程序的工作方式模型的方法之一是使用统一建模语言 (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 公共语言运行库使用权限对象实现其对托管代码的强制限制机制。权限对象有三种，各自具有特定的用途：

• 代码访问安全性。这些权限对象用于防止未经授权使用资源和操作。
  
  
• 身份标识。这些权限对象指定运行程序集时所必需的身份标识特征。
  
  
• 基于角色的安全性。这些权限对象提供了一个机制，用于判断用户（或用户的代理人）是否具有特定身份标识，或者是否是指定角色的成员。PrincipalPermission 对象是唯一基于角色的安全性权限对象。
  
  托管代码可以使用 Principal 对象（包含对 Identity 对象的引用）来判断当事人的身份标识或角色。把 Identity 对象和 Principal 对象与用户、组帐户等大家所熟悉的概念比较可能会更容易理解。在 .NET Framework 中，Identity 对象表示用户，而角色表示成员身份和安全性环境。Principal 对象封装了 Identity 对象和角色。.NET Framework 中的应用程序根据 Principal 对象的身份标识或角色成员身份（后者更常见）授予 Principal 对象权限。
  
  数据访问逻辑组件中的安全性建议
  
  数据访问逻辑组件的设计目的是供其他应用程序组件使用，它也是您的应用程序代码中在调用程序可以访问数据之前实现安全性的最后一个地方。
  
  通常，数据访问逻辑组件可以依赖于由调用程序设置的安全性环境。然而，有些情况下数据访问逻辑组件必须执行自己的授权检查，以确定是否允许当事人执行所请求的操作。授权在身份验证后进行，并使用当事人身份标识与角色等有关信息来确定该当事人可以访问的资源。
  
  在以下情况下，应在数据访问逻辑组件层次上执行授权检查：
  
  
• 需要与不完全信任的业务过程开发人员共享数据访问逻辑组件
  
  
• 需要保护对数据存储提供的强大功能的访问
  
  在定义了 Identity 对象和 Principal 对象后，可以用三种方式执行基于角色的安全性检查：
  
  
• 使用 PrincipalPermission 对象执行强制性安全性检查。
  
  
• 使用 PrincipalPermissionAttribute 属性执行说明性安全性检查。
  
  
• 使用 Principal 对象中的属性和 IsInRole 方法执行显式安全性检查。
  
  以下代码示例显示了如何使用 PrincipalPermissionAttribute 为数据访问逻辑组件类中的方法指定基于角色的声明性安全性检查：
  
  

  using System; using System.Security.Permissions; public class CustomerDALC { public CustomerDALC() { } // 使用 PrincipalPermissionAttribute 要求此方法的调用程序 // 具有一个名为“MyUser”的身份标识，并且属于角色“Administrator”。 [PrincipalPermissionAttribute(SecurityAction.Demand, Name="MyUser", Role="Administrator")] public void DeleteCustomer(string customerID) { // 在此处删除客户代码 } }

  
  
  
  
  以下代码显示了如何创建具有所需身份标识和角色的 Principal 对象，以便对 CustomerDALC 对象调用 DeleteCustomer 方法：
  
  

  using System; using System.Security.Principal; using System.Threading; public class MainClass { public static int Main(string[] args) { Console.Write("用户名:"); string UserName = Console.ReadLine(); Console.Write("密码:"); string Password = Console.ReadLine(); if (Password == "password" && UserName == "MyUser") { // 创建一个名为“MyUser”的通用身份标识 GenericIdentity MyIdentity = new GenericIdentity("MyUser"); // 创建角色 String[] MyString = {"Administrator", "User"}; // 创建一个通用当事人 GenericPrincipal MyPrincipal = new GenericPrincipal(MyIdentity, MyString); // 设置此线程的当前当事人，以用于基于角色的安全性 Thread.CurrentPrincipal = MyPrincipal; } // 创建一个 CustomerDALC 对象，并尝试调用它的 DeleteCustomer 方法。 // 仅在当前当事人的身份标识和角色合格时这一步骤才能成功。 CustomerDALC c = new CustomerDALC(); c.DeleteCustomer("VINET"); } }

  
  
  Windows 身份验证
  
  理想情况下，在连接到数据库时应使用 Windows 身份验证而不是 SQL Server 身份验证。然而，应使用服务帐户并避免模拟连接到数据库，因为它会妨碍连接池。连接池需要相同的连接字符串；如果尝试使用不同的连接字符串打开数据库，就会创建单独的连接池，而这将限制可缩放性。
  
  有关 Windows 身份验证和连接池的详细信息，
  
  安全通信建议
  
  要实现调用应用程序与数据访问逻辑组件之间的安全通信，请考虑以下建议：
  
  
• 如果数据访问逻辑组件是通过各种层的线路调用的，并且信息交换包含需要保护的机密信息，则应使用分布式组件对象模型 (DCOM)、安全套接字层 (SSL)、安全 Internet 协议 (IPSec) 等安全通信技术。
  
  
• 如果数据是加密存储在数据库中，则通常由数据访问逻辑组件负责数据的加密与解密。如果信息暴露会导致巨大损害，则必须考虑保护与数据访问逻辑组件进行通信的通道。
  
  业务实体组件中的安全性建议
  
  如果将业务实体实现为数据结构（如 XML 或 DataSet），则不需要实现安全性检查。然而，如果将业务实体实现为带有 CRUD 操作的自定义业务实体组件，请考虑以下建议：
  
  
• 如果将实体提供给您不完全信任的业务过程，应在业务实体组件和数据访问逻辑组件中实现授权检查。然而，如果在这两个层次上都实现检查，可能会产生保持安全性策略同步的维护问题。
  
  
• 业务实体组件不应处理通信安全性或数据加密，应把这些任务留给相应的数据访问逻辑组件。
  

部署

本节提供一些建议以帮助您确定如何部署数据访问逻辑组件和业务实体组件。

部署数据访问逻辑组件

部署数据访问逻辑组件的方法有两种：

与业务过程对象一起部署数据访问逻辑组件。这种部署方法具有最佳的数据传输性能，还有一些额外的技术优势：

• 事务处理可以在业务过程对象和数据访问逻辑组件之间无缝流动。然而，事务处理不能跨越远程通道无缝流动。在远程方案下，需要使用 DCOM 来实现事务处理。此外，如果业务过程与数据访问逻辑组件被防火墙分开，还需要打开这两个物理层之间的防火墙端口以启用 DTC 通信。
  
  
• 一起部署业务过程对象和数据访问逻辑组件可以减少事务处理失败节点的数目。
• 安全性环境自动在业务过程对象和数据访问逻辑组件之间流动，无需设置当事人对象。
• 与用户界面代码一起部署数据访问逻辑组件。有时需要直接从 UI 组件和 UI 过程组件使用数据访问逻辑组件。为提高 Web 方案下的性能，可以与 UI 代码一起部署数据访问逻辑组件；这种部署方法可以使 UI 层充分利用数据读取器流以获得最佳性能。然而，在使用这种部署方法时必须牢记以下事项：
  
  
  • 不与 UI 代码一起部署数据访问逻辑组件的一个常见原因是防止通过 Web 领域直接对数据源进行网络访问。
    
    
  • 如果您的 Web 领域部署在 DMZ 环境中，则必须打开防火墙端口才能访问 SQL Server。如果使用 COM+ 事务处理，还必须为 DTC 通信打开其他的防火墙端口。
  部署业务实体
  
  应用程序的许多不同层都要使用业务实体。根据业务实体的实现方式，如果您的应用程序跨越各个物理层，则需要将业务实体部署到多个位置。下面列出了在不同实现方案中部署业务实体的方法：
  
  
• 部署作为有类型的 DataSet 实现的业务实体。有类型的 DataSet 类必须由数据访问逻辑组件和调用应用程序访问。因此，建议在一个要部署在多个层的公共程序集中定义有类型的 DataSet 类。
  
  
• 部署作为自定义业务实体组件实现的业务实体。根据数据访问逻辑组件中定义的方法签名，自定义实体类可能需要由数据访问逻辑组件访问。请遵循与有类型的 DataSet 相同的建议，即在一个要部署在多个层的公共程序集中定义自定义实体类。
  
  
• 部署作为通用 DataSet 或 XML 字符串实现的业务实体。通用 DataSet 和 XML 字符串不表示单独的数据类型。以这两种格式实现的业务实体不存在部署问题。

附录

如何定义数据访问逻辑组件类

以下代码示例定义一个名为 CustomerDALC 的类，它是用于 Customer 业务实体的数据访问逻辑组件类。CustomerDALC 类为 Customer 业务实体实现 CRUD 操作，并提供了其他方法为此对象封装业务逻辑。

public class CustomerDALC
{
  private string conn_string;

  public CustomerDALC()
  {
    // 从安全或加密的位置获取连接字符串
    // 并将其分配给 conn_string
  }

  public CustomerDataSet GetCustomer(string id)
  {
    // 检索包含 Customer 数据的有类型的 DataSet
  }

  public string CreateCustomer(string name,
                               string address, string city, string state,
string zip)
  {
    // 根据传递给此方法的标量参数，在数据库中创建一个
    // 新客户。
    // 从此方法返回 customerID。
  }

  public void UpdateCustomer(CustomerDataSet updatedCustomer)
  {
    // 根据作为类型 CustomerDataSet 的参数发送的 Customer 数据，更新
    // 数据库。
  }

  public void DeleteCustomer(string id)
  {
    // 删除具有指定 ID 的客户
  }

  public DataSet GetCustomersWhoPurchasedProduct(int productID)
  {
    // 使用通用 DataSet 检索客户，因为此方法
    // 不需要检索与客户关联的全部信息
  }
}

如何使用 XML 表示数据的集合和层次结构

以下示例显示了如何在 XML 文档中表示数据的集合和层次结构。该 XML 文档表示客户的一个订单；注意，元素 <OrderDetails> 包含一个该订单的详细信息集合。

<Order xmlns="urn:aUniqueNamespace">
  <OrderID>10248</OrderID>
  <CustomerID>VINET</CustomerID>
  <OrderDate>1996-07-04</OrderDate>
  <ShippedDate>1996-07-16</ShippedDate>
  <OrderDetails>
    <OrderDetail>
      <ProductID>11</ProductID>
      <UnitPrice>14.00</UnitPrice>
      <Quantity>12</Quantity>
    </OrderDetail>
    <OrderDetail>
      <ProductID>42</ProductID>
      <UnitPrice>9.80</UnitPrice>
      <Quantity>10</Quantity>
    </OrderDetail>
    <OrderDetail>
      <ProductID>72</ProductID>
      <UnitPrice>34.80</UnitPrice>
      <Quantity>5</Quantity>
    </OrderDetail>
  </OrderDetails>
</Order>

如何在 .NET 应用程序中编程应用样式表

要在 .NET 应用程序中编程应用样式表，请执行以下步骤：

1. 导入 System.Xml.Xsl 命名空间，如以下代码所示。System.Xml.Xsl 命名空间包含 .NET Framework 类库中的 XSLT 转换类。
   
   

   using System.Xml.Xsl;

   
   
   
2. 创建一个 XslTransform 对象，如以下代码所示：
   
   

   XslTransform stylesheet = new XslTransform();

   
   
   
3. 将所需样式表加载到 XslTransform 对象，如以下代码所示：
   
   

   stylesheet.Load("MyStylesheet.xsl");

   
   
   
4. 调用 XslTransform 对象的 Transform 方法，如以下代码所示。调用 Transform 方法指定 XML 源文档和结果文档的名称。
   
   

   stylesheet.Transform(sourceDoc, resultDoc);

如何创建有类型的 DataSet

可以使用有类型的 DataSet 表示业务实体。创建有类型的 DataSet 的方法有多种：

• 从 Microsoft Visual Studio ®.NET 中的数据适配器创建
  
  
• 从 Visual Studio .NET 中的 XSD 架构文件创建
  
  
• 使用 XSD 架构定义工具 (xsd.exe) 从 .NET Framework 命令提示窗口创建
  
  注意：也可以编程定义有类型的 DataSet，即从 DataSet 继承并定义方法、属性和嵌套类以表示该 DataSet 的结构。最简单的方法是使用以下过程之一创建一个有类型的 DataSet，然后将此有类型的 DataSet 类用作将来您自己的有类型的 DataSet 类的基础。

使用数据适配器创建有类型的 DataSet

要使用数据适配器创建有类型的 DataSet，请执行以下步骤：

1. 在 Visual Studio .NET 中，向您的窗体或组件添加一个数据适配器。在数据适配器的配置向导中，指定该数据适配器的连接信息。同时根据具体情况，为数据适配器的 Select、Insert、Update 和 Delete 命令指定 SQL 字符串或存储过程。
   
   
2. 在组件设计器中，在数据适配器对象上单击鼠标右键，然后单击 Generate DataSet（生成 DataSet）。
   
   
3. 在 Generate DataSet（生成 DataSet）对话框中，单击 New（新建），键入新 DataSet 类的名称，然后单击 OK（确定）。
   
   
4. 为确认已创建该有类型的 DataSet，可以在解决方案资源管理器中单击 Show All Files（显示所有文件）按钮。展开 XSD 架构文件的节点，确认存在一个与 XSD 架构相关联的代码文件。该代码文件定义了新的有类型的 DataSet 类。

从 XSD 架构文件创建有类型的 DataSet

要使用 Visual Studio .NET 从 XSD 架构文件创建有类型的 DataSet，请执行以下步骤：

1. 在 Visual Studio .NET中，创建一个新项目或打开一个现有项目。
   
   
2. 为项目添加一个现有的 XSD 架构，或在组件设计器中创建一个新的 XSD 架构。
   
   
3. 在解决方案资源管理器中，双击 XSD 架构文件，在组件设计器中查看该 XSD 架构。
   
   
4. 在组件设计器中选择主 XSD 架构元素。
   
   
5. 在 Schema（架构）菜单中，单击 Generate DataSet（生成 DataSet）。
   
   
6. 为确认已创建该有类型的 DataSet，可以在解决方案资源管理器中单击 Show All Files（显示所有文件）按钮。展开 XSD 架构文件的节点，确认存在一个与 XSD 架构相关联的代码文件。该代码文件定义了新的有类型的 DataSet 类。

使用 XSD 架构定义工具 (xsd.exe) 创建有类型的 DataSet

XML 架构定义工具可以从 XSD 架构文件、XDR 架构文件或 XML 实例文档生成有类型的 DataSet。以下命令使用名为 XsdSchemaFile.xsd 的 XSD 架构文件，在当前目录中名为 XsdSchemaFile.cs 的 Visual C# 源文件中生成一个有类型的 DataSet：

xsd /dataset /language:C# XsdSchemaFile.xsd

如何定义业务实体组件

以下示例显示了如何为 Product 业务实体定义自定义实体类：

public class ProductEntity
{
  // 专用字段，用于保存 Product 实体的状态
  private int productID;
  private string productName;
  private string quantityPerUnit;
  private decimal unitPrice;
  private short unitsInStock;
  private short unitsOnOrder;
  private short reorderLevel;

  // 公共属性，用于公开 Product 实体的状态
  public int ProductID
  {
    get { return productID; }
    set { productID = value; }
  }
  public string ProductName
  {
    get { return productName; }
    set { productName = value; }
  }
  public string QuantityPerUnit
  {
    get { return quantityPerUnit; }
    set { quantityPerUnit = value; }
  }
  public decimal UnitPrice
  {
    get { return unitPrice; }
    set { unitPrice = value; }
  }
  public short UnitsInStock
  {
    get { return unitsInStock; }
    set { unitsInStock = value; }
  }
  public short UnitsOnOrder
  {
    get { return unitsOnOrder; }
    set { unitsOnOrder = value; }
  }
  public short ReorderLevel
  {
    get { return reorderLevel; }
    set { reorderLevel = value; }
  }

  // 执行本地化处理的方法和属性
  public void IncreaseUnitPriceBy(decimal amount)
  {
    unitPrice += amount;
  }
  public short UnitsAboveReorderLevel
  {
    get { return (short)(unitsInStock - reorderLevel); }
  }
  public string StockStatus
  {
    get 
    { 
      return "库存："+ unitsInStock + "，订购：" + unitsOnOrder;
    }
  }
}