** 2. ** ** Data Entity Façade ** ** **
代码 2 ：传统 Data Entity
// Customer1 ：包含基本字段的 Customer ，属轻量级 Data Entity ** **
[ ** Serializable ** ()]
public class ** Customer1 ** : xxx // xxx 表示可能存在的基类
{
public string Id;
public string Name;
public string Phone;
public ** Customer1 ** () {...}
}
// Customer2 ：从 DataSet 继承的 Customer ，又称 Typed DataSet
[ ** Serializable ** ()]
public class ** Customer2 ** : System.Data. ** DataSet **
{
private ** CustomersDataTable ** tableCustomers;
private ** OrdersDataTable ** tableOrders;
private ** DataRelation ** relationFK_Orders_Customers;
public ** Customer2 ** () {...}
...
}
实际上，还有一些方案中可能采用了混合模式，比如：虽然从
DataSet 继承（简单的可以直接从 DataTable 继承），但只实现 Typed
DataSet 的部分功能；或者，虽然包含了基本字段，但在内部实现了
数据填充或转换（在 PetShop 中，数据通过 DAL 以 Reader 方式获取
并填充至 Data Entity ，并没有直接使用 Data Entity 进行转换）；还有
一种最彻底的方式：直接采用 Reader 作为 Data Entity 进行 Cross
Layer 数据交换！这样，性能是最高了，但也给其它 Layer 开发人员
带来了一些不必要的烦恼 L 。
对于只包含基本字段的 Data Entity ，使用起来非常简单，同时还
能以自己比较熟悉的方式编写程序，然而，付出的代价也不小：对
于比较复杂的 Case ，处理起来就不那么得心应手（即使 Framework
提供了这些功能，却很不 ** Ease of Use ** ，这个可从 Borland ECO 所带
的 OCL 中略知一二， .NET Framework ObjectSpaces 中所带的 OPath
也是半斤八两 L ）！
幸好，上述的缺点正是 Typed DataSet 之强项！
虽然体形庞大，但不失灵活，这就是 ADO.NET 带给我们的“礼
物” J 不得不承认，用 Typed DataSet 虽然可能导致一系列问题（性
能，维护），但有时候我们还真是愿意体会这种“痛，并快乐着”的
感觉（当然了，这种感觉并不仅仅限于处理复杂 Case 时的 Ease of Use
体验）！
Duwamish 这样做了，作者的前一个项目也这样做了，您是不是
也准备这样做呢（系统架构师们不定又要大发雷霆了 J ）？
Ok ，说这么多，就一个目的：当然是“隆重推出”作者自己“苦
心孤诣”多年却被“无数”系统架构师“否决”的 Data Entity ！实战
没机会，管它呢，先发个稿子到这里，待大家一起讨论讨论，看看
是否有出头之日 J 。