《设计数据层组件并在层间传递数据》部分摘要

《设计数据层组件并在层间传递数据》笔记

学习向 Microsoft .NET 应用程序公开数据的最佳方式，以及如何实现一个有效的策略以便在分布式应用程序的层间传递数据

主要是想为了公司的最近的项目找到一个比较好的持久/业务层设计，因为已经初步决定使用自定义实体来作为输入/输出参数，所以仅对其进行分析。

 
1.  Web 窗体中的数据绑定。如果不实现 IBindingList 接口，则不能将实体实例的数据绑定到 Web 窗体中的控件。然而，如果只想绑定集合，则可以使用数组或 .NET 集合而不必在自定义实体中实现 IBindingList 接口。可以将用户界面控件绑定到 Windows 窗体和 ASP.NET 应用程序中的自定义实体。有两种可能的方案：

• 在用户界面控件上绑定单个业务实体。以下代码示例显示了如何从 OrderDALC 对象获取一个 OrderEntity 对象并将其绑定到 Windows 窗体的控件上。当用户更改这些控件中的值时，基础 OrderEntity 对象中的数据也将自动更改。例：
  
  OrderEntity order = dalcOrder.GetOrder(10248);
  // 将 OrderEntity 的 OrderID 属性绑定到 TextBox 控件。
  textBox1.DataBindings.Add("Text", order, "OrderID");
  
  
  // 界面做一定修改以后……
  dalcOrder.UpdateOrder(order);
• 将业务实体集合绑定到 DataGrid 控件。以下代码示例显示了如何从 OrderDALC 获取一个 OrderEntity 对象数组并将其绑定到 Windows 窗体的 DataGrid 控件。DataGrid 分别用网格中的一行显示每个数组元素（即每个 OrderEntity 对象）。

 

2. 公开内部数据更改的事件。 自定义实体可以在业务实体状态修改时产生事件。这些事件可用于获得丰富的客户端用户界面设计，因为这使得无论数据显示在哪里都可以对其进行刷新。以下代码示例显示了如何在 OrderEntity 类中产生业务实体相关事件：

// 为所有业务实体事件定义公用事件类
public class EntityEventArgs : EventArgs
{
  // 定义事件成员，用于提供有关事件的信息
}

// 定义一个代理，用于为业务实体相关事件指定签名
public delegate void EntityEventHandler(Object source, EntityEventArgs e);

// 定义自定义实体类，它可以在业务实体状态改变时产生事件
public class OrderEntity
{
  // 定义业务实体状态改变的“before”事件和“after”事件
  public event EntityEventHandler BeforeChange, AfterChange;

  // 专用字段，用于保存业务实体的状态
  private int orderID;

  // 公共属性，用于提供业务实体的状态
  public int OrderID
  {
    get { return orderID; }
    set
    { 
      BeforeChange(this, new EntityEventArgs());   // 产生“before”事件
      orderID = value;
      AfterChange(this, new EntityEventArgs());    // 产生“after”事件
    }
  }
  // 必要时使用更多成员
}

使业务实体可序列化。使业务实体可序列化可以将业务实体的状态保持在中间状态而不进行数据库交互。这样可以方便脱机应用程序的开发和复杂用户界面过程的设计，即在完成前不会影响业务数据。

缺点及解决方案：

• 业务实体集合：对于User实体，建立UserCollection
• 序列化。您必须在自定义实体中实现自己的序列化机制。可以使用属性来控制实体组件的序列化方式，也可以通过实现 ISerializable 接口来控制自己的序列化。
• 表示业务实体中的复杂关系和层次结构，比较复杂，使用UserCollection之类的类可以达到要求，不过项目简单，不需要做太多复杂的关系和层次结构。
• 搜索和排序数据，可以在存储过程中排序，或者在页面上用javascript排序，内部排序实在要实现的话，可以考虑通过实现 IComparable 接口以便将实体组件保存在一个 SortedList 集合或 Hashtable 集合中。
• 对于并发的问题不用考虑，因为几乎没有几个用户改同一条数据的情况（此项目中）。
• 部署：不是问题。
• 开发时间长：对开发时间要求低
• 事务处理，不需要进行多个界面的事务处理，实在要实现，可以考虑保存修改的数据的方式处理。
• 其他