<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
再回到最初的代碼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的功能，又可以在此基礎上進行擴充。