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。