一、簡介
作為開發人員，當我們在學習新技術時，例子可能是我們最大的敵人。而教程往往設計得易於理解，但是同時，它們常常加固了懶惰，低效性，甚至於危險的編碼習慣。再也沒有比ADO.NET示例更能說明問題的了。在本文中，我們將准備分析一下強類型對象對於你的數據庫開發的意義以及為什麼在沒有例子的情況下你應該在應用程序中盡量使用強類型對象。
具體地說，我們將分析怎樣在Visual Studio 2005中創建和使用強類型DataSet。正如本文所探討的，相對於其它可選的弱類型化的數據存取技術，強類型DataSet提供了很多優點；並且，借助於Visual Studio 2005，創建和使用強類型DataSet比以往更為容易。
二、強類型對象基礎及優點
為了理解強類型化的含義，不妨讓我們先考慮一下約會的例子。如果你是一個單身漢，那麼，你盼望與什麼類型的人約會呢？你可能已經有了自己具體的標准，如富裕且吸引人或可能是居住條件優越而性感。無論你的條件如何，當你決定想與誰在一起呆更長的時間時，你都難免有一套自己的約會標准。如果你很明智，可以列出一個經過事先深思熟慮的列表，這樣可以幫助你節約不必要的感情付出。把一項"非酗酒"的條件加入到你的約會標准中將會節約你大量的時間，並且允許你把你的時間和精力用於與更好的候選者約會。
你可能疑惑，這怎麼能與編程進行比較呢？請聽我的解釋。ADO.NET數據存取對象的設計是為了實現最大的靈活性。除非你遇到相當大的麻煩，否則，當你從數據庫讀取數據時，你都會使用大量普通的未經類型化的對象-當然，.NET框架完全允許這樣做。而使用我們的約會類比法，總是把你的關系數據當作泛型對象則有點象承認"我只與滿足我條件的人約會"。難道你不能稍微放寬一些條件嗎？作為你的朋友，我必須建議你"先確定一些標准，再精簡一下你的列表！"也許更好些。
正如忽視篩選你要約會的人能夠導致未來的關系問題，與你的對象保持"松耦合"能夠給你的代碼帶來錯誤。另外，因為如果你讓任何舊對象"出入"你的子程序的話，那麼，直到你的應用程序在運行時刻執行時，你可能才會知道存在問題。在我們的日期約會類比中，在運行時刻捕獲錯誤很類似於你與你的約會者在一家時髦的意大利餐館進行一場痛苦而尴尬的討論。是的，你發現了這個問題；但是，如果你已經事先計劃好的話，那麼你的結果就不會是"一群用餐者盯著你，而你滿身是意大利烤碎肉卷"。如果你簡單地把一些更緊密的標准應用於你的代碼中，那麼在你的應用程序開始運行前（在編譯時刻）你就能夠捕獲錯誤。例如，請考慮下面的示例代碼：
string FirstName = myrow.("FirstName").ToString();
上面的DataRow就是非類型化的；結果，你必須以一個串形式作為你要查詢的列名來存取這個值(或者，使用這個列集合中的列的索引值)。很可能，這個列真正存在。一個DataRow列的數據類型是對象；我們假定FirstName列的基本數據類型是字符串，但是，我們必須顯式地把它轉化成一個字符串以便使用它。如果列名發生變化（例如，你把它改為PersonFirstName），那麼編譯器是不能通知你的。千萬不要這樣！因此，如果你的代碼看起來更象如下形式，那麼你的生活就會更容易些而你的代碼將更為可靠：
string FirstName = PersonRow.FirstName;
在第二個例子中，我們擁有一個強類型行，並且我們知道FirstName屬性是字符串類型。在此，不會出現雜亂的列名，而且也不存在雜亂的對象轉換問題。編譯器為我們作類型檢查，並且我們可以繼續進行其它任務而不必擔心是否我們已經正確輸入了列名。
對於所有其它列也是如此；總之，當你能夠使用一個更為具體的類型時，你永遠不應該使用一個泛型對象。但是，請等一下。該強類型對象出自何處？我想我能夠告訴你這些對象是為你自動創建的。然而，正如要建立良好的關系需要時間和精力一樣，強類型化你的對象也需要付出其它努力。好的方面在於，這裡所花費的額外時間是值得的，而且節省了將來更多的花在調試上的時間。
存在若干種可以實現強類型化的方法，在本文余下的部分中，我們將討論怎樣在Visual Studio 2005中創建強類型DataSet；當然，還將分析一下這樣做的優點和缺點。
