一、 引言
說實在的，我對ASP.NET 2.0與Visual Studio 2005之間的關系有些喜歡也有些討厭；但是，我最終還是
|
|
決定把我的大多數內部應用程序遷移到2.0并且決不后悔。基本上，ASP.NET 2.0中存在太多的新的特征使我的生活變得更為輕松，并且從此以后再也不會返回到以前的1.1版本中編程了。
到目前為止，這個平臺一直工作良好。我已經發現了其中存在的許多改進能夠大量地降低編碼的復雜性和編碼數量，在性能方面大約提高了10～20%，并且減少了內存需求量（這對于大型應用程序而言是十分重要的），但是對我的工作來說幾乎沒有太大的作用。
把2.0特征加入到現有應用程序中絕對不是一夜之間的事情。但是，隨著我逐漸地習慣快速地把大量的2.0特征加入到我的新式應用程序中，我的最后感覺是：如果再回到ASP.NET 1.1和VS 2003的話，那將是一個很大的后退。
二、 優點評析
下面，讓我們來逐步剖析這個新產品中的主要變化，首先來看一下它的優點。
(一) Visual Studio 2005基于文件的工程開發
現在，在Visual Studio 2005中，你能夠把一個目錄作為一個web工程來打開，這是一種相當不錯的改進。在我的開發機器上，我可能有50個不同的web工程。使用以前的VS2003，要把所有這些作為IIS中的虛擬目錄加以配置和維護并且使工程實現正確地引用是令人相當頭疼的事情。你不這樣認為嗎？你是否想把某些工程移動到一臺新機器上？在VS2005中，你只需要簡單地指向一個目錄就可以打開工程。你完全可以使用本地的Web服務器構建方式來運行應用程序，這樣以來就免除了配置Web服務器的需要。
這個特征特別適合于共享示例的開發者—任何想檢查一個示例web應用程序的開發人員都不必經受基于IIS進行配置的痛苦。現在，借助于基于文件的工程，你能夠—至少在開發場所下—實現真正的“xCopy”工程。這個特征相當偉大，但是也不無缺點（一會兒后我們會詳及）。
【另注】我接觸到的每一位都喜歡構建到Visual Studio內部的Cassini web服務器。當然，我也喜歡，因為它極大地簡化了許多問題的處理。然而，有關它的使用也存在一些缺點。主要是在使用過程中應當避免Cassini與IIS之間的相互干擾。例如，Cassini能夠把所有的請求傳遞給ASP.NET而忽略擴展內容。如果你擁有處理特定的文件類型的定制的處理器(例如，動態地構建Excel報告，等等)，那么，你必須記住，當發布你的應用程序時，你要在IIS中為擴展內容建立定制的映射；否則的話，IIS不會把請求傳遞給ASP.NET。我接觸過許多朋友在發布時花費大量的時間來解決他們的應用程序中的問題，因為他們在開發過程中從不擔心Cassini中的配置設置問題。
(二) 母版頁面
現在，你可以定義一個能夠在你的應用程序中重用的母版（Master）頁模板。使用這個功能能夠節約你大量的開發時間。事實上，在2.0版本出現以前，已經存在基于ASP.NET 1.x版本的這種概念，但是對于我來說，吸引我的最關鍵的特征在于，Visual Studio提供了對它的可視化支持。這可以使你看到母版的布局，其中ContentPlaceholders可以應用于每一個頁面中以提供頁面級內容。
除了設計器提供的重要的可視化方面外，母版頁模板還提供了一種良好的方式來把彼此相關的可重用的代碼聯系到一起。母版頁面的目的是，把以前需要使用若干用戶控件(例如，Header，Footer和Sidebar)才能實現的功能融合到一起，從而使它們能夠比以前更為有效地實現邏輯分離。
【另注】你還能夠在運行時刻動態地改變母版頁面，從而實現更大的靈活性。這一支持使用戶能夠改變一個應用程序的整體外觀感覺；而且這種效果是僅憑借切換層疊式樣表所無法實現的。
(三) 用戶控件可視化描述
說實在的，我非常希望自己在設計時就能看到整個頁面的樣子。就象母版頁面一樣，現在，Visual Studio 2005能夠在Web表單編輯器內顯示一個生成的用戶控件。不再象是以前的老式的、非描述性的灰色的方框加上一個控件名，現在，你能夠在設計器內得到一個全面生成的恰當到位的控件。雙擊它，則VS就能把你導航到用戶控件設計器。在我的開發中，我一般不會大量地使用用戶控件，而是使用母版頁面來替換我的許多現有的控件，但是我發現這種用戶控件可視化描述使設計模式更為有用了。對于我的現有1.1版本的應用程序來說，尤其如此—我的這些程序中通常仍然使用這樣的控件來表達頁面的頁眉，側欄和頁腳。
【另注】完全自動地生成用戶控件極大地節約了開發時間。當然，我還需要花費不少的時間從IDE到一個瀏覽器來回切換以觀察用戶控件最終生成的樣子。僅此而已。
(四) 泛型
不錯，這并非是一個ASP.NET特有的特征，但是.NET 2.0中泛型的引入大大豐富了代碼的編寫。以前，在創建定制集合時，我常常非常小心；坦誠地說，反反復復地從CollectionBase進行派生然后重新實現相同的代碼是一件非常折磨人的工作。對于定制控件開發，特別在ASP.NET中開發時，我發現當你需要集合特性時使用泛型集合效果相當好。
|
|
你只需簡單地使用列表或一個特定的泛型集合，然后把它作為該控件的一個屬性—問題就這么簡單！Visual Studio能夠看到這個集合；并且，在大多數情況下，它還能夠為你提供相應的集合編輯器。通過使用泛型列表，你可以很容易地使用強類型化列表來代替許多基于ArrayList的列表，這往往使編碼更為清晰。
最后，在業務對象內使用動態的類型替換消除了對令人“膽戰心驚”的初始化編碼（以前，在每一個業務對象中都要進行這種初始化以指定哪個實體類型與之相關聯）的需要。在泛型出現以前，往往需要借助于一個小型編碼代理來把業務對象和實體綁定到一起。現在，有了泛型類型后，不再需要這樣的編碼，而代之以一個泛型類型參數。此后，所有的類級代碼就能夠使用泛型類描述在運行時刻自動地生成正確的類型。借助于一個類型化參數和一組父類級方法，現在再也不需要從我的所有業務對象中剪切和粘貼大量的代碼。其實，還存在許多使用泛型的場所；而且如今，我發現不使用泛型類型很多問題變得十分棘手，特別是在處理與集合相關的內容時。
【另注】泛型將會被廣泛應用于集合及業務對象操作方面，而且，你也可以在頁面基類和用戶控件開發中從中獲益。最近，我在網上看到有人構建一個泛型基頁面實現自動地加載業務對象數據并建立相應的Ajax回調機制以便更新這些對象。你看，以前在每一個新頁面中實現起來如此頭疼的事情一下變得如此簡單了！
(五) 支持嵌入式資源
我比較喜歡把大量的定制控件用于我自己的應用程序中。經常情況下，這些控件都會依賴于特定的資源，例如圖像，CSS文件，XML資源等等。此時，任何這些控件的用戶必須記住要在他們的應用程序中發布相應的文件。如今，在ASP.NET開發中，你可以容易地把需要的Web資源嵌入到一個工程中，然后經由一個ASP.NET生成動態的URL來存取它們。為此，你只需要簡單地把[WebResource]屬性添加到你的控件的AssemblyInfo文件中，然后使用Page.ClientScript.GetWebResourceUrl來檢索包含這些資源內容的URL即可。
(六) Visual StudioASP.NET代碼編輯器
Visual Studio 2005代碼編輯器比2003版本前進了一大步。我認為，最重要的新“特征”在于，新的編輯器不會自動地“打亂”我的代碼格式，除非我重新格式化文檔。例如，我想讓我的內容按我喜歡的方式進行組織，然而，當我使用VS2003時這卻成了一個問題—無論何時把新的控件添加到頁面系統都會重新格式化HTML。在VS2005中，編輯器在大多數情況下會保留用戶自己的代碼格式，并且還會提供一種更好的處理—把控件標記插入到代碼中。
一個真正提高生產效率的改進是，在新的HTML編輯器中引入了智能感知技術—而且出現在每一處位置！我經常在一個頁面內嵌入<%=%>表達式，而智能感知意味著它會幫助我避免錯別字。ASP.NET 2.0還會編譯頁面并且檢查生成的嵌入式腳本代碼，以便及早地在設計時刻而不是在運行時刻才捕獲HTML標記中的錯誤。
智能感知適合于所有的控件，包括你自己的定制控件，因此你不必再提供一種私有類型模式文件。Visual Studio能夠簡單地找到你的控件并且在內部管理智能感知。智能感知支持真是太好了，有時它甚至能夠“超越”可視化設計器。一會兒后，你就會明白為什么這可能比你想像的更為重要。
【另注】作為一名最近才從Visual Basic轉到C#的新手，我特別欣賞Visual Studio 2005提供的C#智能感知支持。在Visual Studio以前的版本中好象在對VB和C#的智能感知支持方面存在很大的差距；并且，當我分析C#代碼時，我常常發現我自己十分需要有一種VB風格的智能感知幫助。現在，現在這種差距消失了，而且語言之間的切換也更為容易了。