回到最初的代码1，作者通过DAF的不同调用总共得到了5种不同的Data Entity对象：DataTable，DataSet，MyCustomer，Ilist，DbDataReader，奇怪的是，只有第三次调用才返回真正的Data Entity对象：MyCustomer，这不是和上面所说的Data Entity Façade自相矛盾吗？

且慢，下面的代码或许能够说明一些问题：




代码5：Def如何表现不同数据类型？

// DefBase：提供大部分应用程序所需的基本Data Entity支持，

// 包括Collection，ADO.NET

[Serializable()]

public abstract class DefBase : IList, IDictionary

{

public static implicit operator DataSet(DefBase def)

{

return def._dst;

}

public static implicit operator DataTable(DefBase def)

{

return def._tbl;

}

public static implicit operator DbDataReader(DefBase def)

{

return def._rdr;

}

...

}


















































上面的DefBase说明了四个问题：



（1） 对于继承接口有一定难度的数据类型，如：DataTable，DataSet，DbDataReader，统统采用implicit operator进行内部数据类型转换，转换后的结果即为Data Entity的实际数据类型，这样调用比较方便，也容易扩展（例如：本来需要返回DataTable，今后可能改为DbDataReader或其它数据类型，此时，Data Entity / Data Access的接口都无须改动，调用者也只是改用其它implicit operator进行访问即可得到想要的数据）；

（2） 对于继承接口非常方便的数据类型，如：Ilist，直接继承接口并实现之（上述的DbDataReader也可以通过继承IDataReader实现，但就目前的ADO.NET 2.0而言，由于实现IDataReader的类几乎全部从DbDataReader继承，所以，直接使用implicit operator更为实用）！

（3） 无论上面那种类型，Data Entity内部都会维护一个指向实际数据成员的对象，该对象反映了数据的真实面目；

（4） 对于只需要暴露基本对象字段的Single Object，直接使用Data Entity本身（MyCustomer）即可，这种情况，就与我们在O/R Mapping中调用Data Entity时一模一样了！



对于DefBase不能解决的问题，就需要具体的应用程序去处理了。例如：考虑到Generic因素，DefBase暂不支持XML数据存储，开发人员就可以在自己的应用程序中建立Customized Data Entity Facade，使其支持XML，然后，具体的Data Entity Class就可以直接从Customized Data Entity Façade继承（当然，如果Data Entity Class无须支持XML，也可从DefBase继承）并使用其XML支持功能！

上面代码3中的MyDef / MyCustomer就是为了这个目的而构建出来，既使用了Framework的功能，又可以在此基础上进行扩充。



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