Silverlight與DataSet搭橋之旅

訊光科技 / Andy Kao

前言

微軟的Silverlight與Adobe的Flex打開了一個新的使用者介面領域，酷炫的3D操作介面及親合的多點觸控能力，讓User有如走進科幻電影的場景當中，加上平板電腦的熱潮，這股新的操作介面將會深深影響到既有的使用者，並成為下一代操作介面的新標準。

因此，有越來越多的企業與軟體業者，開始著手對Silverlight投入不少評估與開發的工作。如果是資料庫的商業應用開發，馬上面臨就是習慣的改變，因為Silverlight是必須採用ORM的架構，就是要將連結的資料表進行明確的Object化(轉成一個個的Class)，這也相對對軟體的開發多了不少步驟與程序，工作量也相對增加。

為此，EEP2010除了提供原有的Entity Framework架構來支援Silverlight頁面開發外，也增加了可以使用傳統的DataSet方式來作為後端處理資料的方案，這樣不但可以保留以前傳統ADO.net的SQL語句習慣，更能沿用舊有的EEP在Server端所開發的商業模組，在完全不修改的情況下，直接讓Silverlight可以連結與存取，來大幅增加Silverlight的應用範圍。
 

Silverlight的資料連接

在企業的資料庫應用軟體中，經常會用到動態SQL語句來得到資料結果，這種資料庫與Table名稱甚至Column名稱都不確定的情況下，返回查詢的數據，對於ASP.NET的Web或Windows表單來說是很容易實現的。但是在Silverlight中確是一件麻煩的事，如果你是透過WCF來傳回資料其類型就必須是確定的，也就是一個定義清楚的數據集合(如Entity這類型)。因此傳回Dataset與DataTable都是遙不可及的。

在Silverlight中可以使用WCF RIA Service或標準的WCF Service或Web Service等方式來取得遠端的資料，無論是哪一種都離不開要連接到一個定義明確的數據集合，也就是說必須是一個Entity或是IEnumerable(非泛型資料集合)，因此動態又抽象的DataSet與DataTable當然就無法使用了。而針對RIA Service或WCF Service來說，在ADO.net架構下，可以選擇使用輕量級的Linq to SQL或重量級的Entity Framework都可以很容易實現與Silverlight的連結，如下圖的方案。

Entity Framework的缺點

問題是不管Linq to SQL還是Entity Framework，對開發者來說都是很不習慣的選擇，雖然優點很多，但缺點也不少，簡單說明如下：

1.      複雜的SubSelect或Left Join的需求無法以Entity的語句下達出來，開發者已經熟習多年的SQL語句是不可能放棄而去學習一個不熟習的Entity語法。

2.      SQL語法是一行一行的Coding方式，很少需求無法滿足，但Entity Framework是封裝起來用，對於開發者來說是不夠彈性與透明的。

3.      目前Entity Framework無法支援所有的資料庫，其Client Provider的版本也很亂，資料庫廠商似乎與微軟不同調，造成廠商不太願意支援EF，但又不得不支援等詭異現象。

4.      Entity Framework是一筆一筆的回存概念，所以當有大批數據要進行異動或  新增時，沒有類似SQL的批次語句可以對應，造成非得必須使用Stored Procedure不可。

5.      開發與維護更為費時，不管是早期的dbml或是現在的edmx，將對於Table Schema的頻繁變動帶來不便，雖有自動化的工具可以重新產生這些ORM的對應程式，但因為操作步驟與效能不佳，徒增開發效能的下降。

EEP新的資料連結

EEP2010當然須保留以WCF Service配合Entity Framework下的資料存取架構，先不要管未來會如何，畢竟是微軟耗費大批人力物力嘔心瀝血之作，在需求不易變更(Table不易更改)之下，還是個很棒的資料存取架構，也許3年5年後，Entity Framework會成為開發主流也說不定。

EEP2010的EF Module SP2版本中，將增加這個新的連結DataSet架構(元件為InfoCommand)，如圖，同樣以WCF的通訊平台來連結到原來.Net Remoting的A/P Server上，並將DataSet的資料以XML的方式序列化轉到Silverlight的Client中，然後再轉成可以與Silverlight架構配合的Entity資料集合，這樣架構的好處是，之前EEP2006/EEP2008與EEP2010所開發的Remoting Server DLL都可以直接作為Silverlight的資料存取服務，完全不用改寫，當然包括所有原來的Server Method也都可以使用，這對於.Net的EEP老客戶來說，真是一大福音。
 

不但如此，原來所開發的Silverlight頁面，也可以重新自由設定要連到WCF Server Package(以Entity Framework為基礎)還是要連到.Net Remoting的Server Package (以DbDataAdapter為基礎)，對於EEP的Silverlight元件與Wizard的開發方式來說，完全不影響，設計的方法與步驟程序都是相同的。
 

總結

當初Silverlight剛出來時，其實就是要共用EEP原有的Remoting Server 來達到A/P Server的服務可以完全沿用，無奈當時的技術不夠成熟，資料不夠充足，未能如願，只能以Entity Framework的架構來實現。如今，雖然晚了1年，但相信這個架構將可以讓EEP的客戶們更有願意來嘗試與開發Silverlight這種RIA的介面，姑且先不考慮因為Silverlight的介面親合或具有多點觸控能力，光是Silverlight在資料展現與操作介面效能的提升，就會讓人躍躍欲試的衝動了。