代碼4：我的Data Entity – 2，Framework中的Data Entity<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
|
// DafBase：提供大部分應用程序所需的基本Data Entity支持， // 包括Collection，ADO.NET
[Serializable()] public abstract class DefBase : IList, IDictionary { protected internal string _typeEntity = EntityType.OBJECT;
// Collection fields protected internal ArrayList _al = null; protected internal Hashtable _ht = null;
// ADO.NET fields protected internal DataSet _dst = null; protected internal DataTable _tbl = null; [NonSerialized()] protected internal DbDataReader _rdr = null;
public DefBase() { } public DefBase(ArrayList al) { this._al = al; this._typeEntity = EntityType.COLLECTION_ARRAYLIST; } ... public DefBase(DataSet dst) { this._dst = dst; this._typeEntity = EntityType.ADOX_DATASET; } public DefBase(DataTable tbl) { this._tbl = tbl; this._typeEntity = EntityType.ADOX_TABLE; } ... } |
以上，就是我的Data Entity小樣了（終於又要見人了J），是不
是感覺很“酷”啊?
坦率地講，根據我的保守估計，八成以上的朋友會有“不敢苟同”之想法，而另外15%可能是不能確定，總有似曾相識（四不象？）卻又不盡相同的味道。至於這剩下的5%，我就不是很清楚了（希望是所見略同吧），如果哪位寫郵件告訴我“這正是我想要的，請你給我一份源碼吧”，估計我會毫不猶豫的立即奉上而不再考慮任何License問題（如果在1天內沒有收到回覆，請您相信是作者開心得暈過去了，要不就是Internet出問題了J）！
Ok，簡單解釋一下：
可能大家已經注意到一個問題，這裏的Def好像並不是Data
Entity的縮寫，那麼，這個“f”到底代表什麼呢？
前面曾經提過，作者的這個數據訪問層解決方案起名字爲Data Access Façade（DAF），參考的當然是GOF23條中的Façade Pattern，所以，有鑑於此，這裏Def中的“f”同樣包含着Façade意思！
是不是有點複雜了？頭暈？沒有關係，且聽一一道來！
代碼2中給出的兩種經典Data Entity模式各有其明顯的優缺點，基本上，就作者瞭解的情況，實際開發中都是以一種統一的方式進行抉擇，難免就顧此失彼（總有些Case是簡單的，也總有些Case是讓人頭疼不已的）。如果，再加上系統架構時必須考慮的其它因素，如：安全，性能，可擴展性（接口/基類），可伸縮性（負載均衡/分佈式處理）等，對於一個稍微上點規模的Enterprise Application，也就不難理解爲何Data Access Layer總是那麼讓人又愛又恨了（Sigh，Data Entity才只是萬里長征第一步啊L）!
所以，爲了解決這個問題，作者感覺有必要搞一個相對比較Generic的解決方案，所要解決的第一個問題就是：Data Entity！
所謂的Def，當然就是：Data Entity Façade，說白了，就是以一
致的方式將數據展現在您的面前！這裏的一致，不僅僅意味在當前應用程序中表現出一致的訪問方式（Interface），還要能夠確保在一致的Interface下支持不同的Data Entity模型（Storage）。而所有這一切，都被隱藏在了一個特別搭建的Data Entity之後，它，就是作者DAF解決方案中的第一步：Data Entity Façade！簡稱爲：Def。