再回到最初的代码 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 的功能，又可以在此基础上进行扩充。