VS2005和ASP.NET2.0中使用強型別資料

一、簡介

作為開發人員，當我們在學習新技術時，例子可能是我們最大的敵人。而教程往往設計得易於理解，但是同時，它們常常加固了懶惰，低效性，甚至於危險的編碼習慣。再也沒有比ADO.NET樣本更能說明問題的了。在本文中，我們將準備分析一下強型別對象對於你的資料庫開發的意義以及為什麼在沒有例子的情況下你應該在應用程式中盡量使用強型別對象。

具體地說，我們將分析怎樣在Visual Studio 2005中建立和使用強型別DataSet。正如本文所探討的，相對於其它可選的弱類型化的資料存取技術，強型別DataSet提供了很多優點；並且，藉助於Visual Studio 2005，建立和使用強型別DataSet比以往更為容易。

二、強型別對象基礎及優點

為了理解強型別化的含義，不妨讓我們先考慮一下約會的例子。如果你是一個單身漢，那麼，你盼望與什麼類型的人約會呢？你可能已經有了自己具體的標準，如富裕且吸引人或可能是居住條件優越而性感。無論你的條件如何，當你決定想與誰在一起呆更長的時間時，你都難免有一套自己的約會標準。如果你很明智，可以列出一個經過事先深思熟慮的列表，這樣可以協助你節約不必要的感情付出。把一項"非酗酒"的條件加入到你的約會標準中將會節約你大量的時間，並且允許你把你的時間和精力用於與更好的候選者約會。

你可能疑惑，這怎麼能與編程進行比較呢？請聽我的解釋。ADO.NET資料存取對象的設計是為了實現最大的靈活性。除非你遇到相當大的麻煩，否則，當你從資料庫讀取資料時，你都會使用大量普通的未經類型化的對象-當然，.NET架構完全允許這樣做。而使用我們的約會類比法，總是把你的關係資料當作泛型對象則有點象承認"我只與滿足我條件的人約會"。難道你不能稍微放寬一些條件嗎？作為你的朋友，我必須建議你"先確定一些標準，再精簡一下你的列表！"也許更好些。

正如忽視篩選你要約會的人能夠導致未來的關係問題，與你的對象保持"松耦合"能夠給你的代碼帶來錯誤。另外，因為如果你讓任何舊對象"出入"你的子程式的話，那麼，直到你的應用程式在運行時刻執行時，你可能才會知道存在問題。在我們的日期約會類比中，在運行時刻捕獲錯誤很類似於你與你的約會者在一家時髦的意大利餐館進行一場痛苦而尷尬的討論。是的，你發現了這個問題；但是，如果你已經事先計劃好的話，那麼你的結果就不會是"一群用餐者盯著你，而你滿身是意大利烤碎肉卷"。如果你簡單地把一些更緊密的標準應用程式於你的代碼中，那麼在你的應用程式開始運行前（在編譯時間刻）你就能夠捕獲錯誤。例如，請考慮下面的範例程式碼：

string FirstName = myrow.("FirstName").ToString();

上面的DataRow就是非類型化的；結果，你必須以一個串形式作為你要查詢的列名來存取這個值(或者，使用這個列集合中的列的索引值)。很可能，這個列真正存在。一個DataRow列的資料類型是對象；我們假定FirstName列的基礎資料型別 (Elementary Data Type)是字串，但是，我們必須顯式地把它轉化成一個字串以便使用它。如果列名發生變化（例如，你把它改為PersonFirstName），那麼編譯器是不能通知你的。千萬不要這樣！因此，如果你的代碼看起來更象如下形式，那麼你的生活就會更容易些而你的代碼將更為可靠：

string FirstName = PersonRow.FirstName;

在第二個例子中，我們擁有一個強型別行，並且我們知道FirstName屬性是字串類型。在此，不會出現雜亂的列名，而且也不存在雜亂的對象轉換問題。編譯器為我們作類型檢查，並且我們可以繼續進行其它任務而不必擔心是否我們已經正確輸入了列名。

對於所有其它列也是如此；總之，當你能夠使用一個更為具體的類型時，你永遠不應該使用一個泛型對象。但是，請等一下。該強型別對象出自何處？我想我能夠告訴你這些對象是為你自動建立的。然而，正如要建立良好的關係需要時間和精力一樣，強型別化你的對象也需要付出其它努力。好的方面在於，這裡所花費的額外時間是值得的，而且節省了將來更多的花在調試上的時間。

存在若干種可以實現強型別化的方法，在本文餘下的部分中，我們將討論怎樣在Visual Studio 2005中建立強型別DataSet；當然，還將分析一下這樣做的優點和缺點。