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