<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
2. Data Entity Façade
代碼2：傳統Data Entity
|
// Customer1：包含基本字段的Customer，屬輕量級Data Entity
[Serializable()] public class Customer1: xxx // xxx表示可能存在的基類 { public string Id; public string Name; public string Phone;
public Customer1() {...} }
// Customer2：從DataSet繼承的Customer，又稱Typed DataSet [Serializable()] public class Customer2 : System.Data.DataSet { private CustomersDataTable tableCustomers; private OrdersDataTable tableOrders;
private DataRelation relationFK_Orders_Customers;
public Customer2() {...} ... } |
實際上，還有一些方案中可能採用了混合模式，比如：雖然從
DataSet繼承（簡單的可以直接從DataTable繼承），但只實現Typed
DataSet的部分功能；或者，雖然包含了基本字段，但在內部實現了
數據填充或轉換（在PetShop中，數據通過DAL以Reader方式獲取
並填充至Data Entity，並沒有直接使用Data Entity進行轉換）；還有
一種最徹底的方式：直接採用Reader作爲Data Entity進行Cross
Layer數據交換！這樣，性能是最高了，但也給其它Layer開發人員
帶來了一些不必要的煩惱L。
對於只包含基本字段的Data Entity，使用起來非常簡單，同時還
能以自己比較熟悉的方式編寫程序，然而，付出的代價也不小：對
於比較複雜的Case，處理起來就不那麼得心應手（即使Framework
提供了這些功能，卻很不Ease of Use，這個可從Borland ECO所帶
的OCL中略知一二，.NET Framework ObjectSpaces中所帶的OPath
也是半斤八兩L）！
幸好，上述的缺點正是Typed DataSet之強項！
雖然體形龐大，但不失靈活，這就是ADO.NET帶給我們的“禮
物”J不得不承認，用Typed DataSet雖然可能導致一系列問題（性
能，維護），但有時候我們還真是願意體會這種“痛，並快樂着”的
感覺（當然了，這種感覺並不僅僅限於處理複雜Case時的Ease of Use
體驗）！
Duwamish這樣做了，作者的前一個項目也這樣做了，您是不是
也準備這樣做呢（系統架構師們不定又要大發雷霆了J）？
Ok，說這麼多，就一個目的：當然是“隆重推出”作者自己“苦
心孤詣”多年卻被“無數”系統架構師“否決”的Data Entity！實戰
沒機會，管它呢，先發個稿子到這裏，待大家一起討論討論，看看
是否有出頭之日J。