实战 .Net 数据访问层 - 3

作者： unknow

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。

下一段：http://www.csdn.net/develop/Read_Article.asp?id=27546

返回顶部

下一篇：实战 .Net 数据访问层 - 2 >>