asp.NET特寫

 創建動態Web頁面的新技術已經以CLR服務為基礎全部重新改寫。到目前為止，所有.NET提供的語言都可用于編寫ASP.NET頁面，但頁面的擴展名和ASP 3.0的不同。具體地說，簡單Web頁面以“.aspx”為擴展名，Web服務以“.asmx”為擴展名（來源于“Assembly”），一種稱為Pagelet的ASP.NET頁面可重用部件以“.aspc”為擴展名。

　　 .NET應用能夠流暢地同時運行.asp和.aspx頁面。舊式的ASP頁面將由asp.dll直接運行，但它不能利用CLR的功能。

　　 現在，.aspx頁面不再解釋執行，而是在第一次調用出現時被編譯成MSIL代碼，然后再以中間代碼運行，就象J2EE環境下的JSP一樣。一個合乎邏輯的結論是性能會有所提升，Microsoft宣稱它可以與Visual Basic 4升級到編譯版本5時應用性能的提升程度相媲美。

　　 除了理解VB.NET引入的所有新概念之外，這些根本性的改變還要求對ASP頁面的編寫方式作較大的改動。為了了解從ASP遷移到ASP.NET所要做的工作，下面我們來分析一下主要改動之處。

　　 這些改動分屬三個層次：

API中的改動
頁面結構的改動
VBScript和VB.NET之間的改動
　　 ASP.NET只允許每個頁面使用一種語言。在DNA中，ASP頁面可以同時使用JScript和VBScript；但ASP.NET不再允許這種用法。

　　 在ASP.NET中，函數必須用HTML < SCRIPT >標記包圍，而且不允許把用于生成HTML代碼的函數分割成多個部分。例如，ASP.NET不允許出現下面這種代碼：

　　 相反，我們必須代之以如下代碼：

< SCRIPT LANGUAGE="VB" runat=server >
Function SayHello()
Response.Write ("< b >< i > ")
Response.Write (" Hello ! ")
Response.Write ("< /i >< /b > ")
End Function
< /SCRIPT >

　　 括起函數調用參數的括號現在是必需的。另外，有的兼容性問題可能源于所有ASP.NET的數組下標都從0開始，而在ASP 3中有的從0開始，有的從1開始。

　　 在VB.NET中，默認情況下參數以值（ByVal）傳遞，而在當前的VBScript中，參數默認以引用傳遞（ByRef）。最后，VB.NET將不再支持默認值或關鍵詞Set、Let。

　　 雖然這些改動都不是重大的、根本性的，但如果要利用CLR以及編譯代碼的優勢就必須修改現有的代碼，這些改動會占據開發者大量的時間。Microsoft已經宣布，用于代碼遷移的工具會隨同.NET平臺一起發布，但從現在起就養成合適的編碼習慣無疑是有益無害的。

　　 至于COM組件，ASP.NET將采用封裝的形式使得原有的COM組件仍舊能夠運行，但這些COM組件將運行在CLR受管理的環境之外，而且受管理以及非受管理環境之間的切換會犧牲一定的性能。因此，很多用戶可能會決定重新把COM組件編寫成COM + 2.0。

　　 ASP.NET引入了服務器端控件，它可能是ASP.NET吸引開發者使用它的一個重要原因。使用這些控件，ASP.NET頁面能夠利用可視或者非可視控件提供的如下高級服務：TreeView（樹形視圖）, ListBox（列表框）, Calendar（日歷），等等。所有這些控件都會分析調用它們的客戶程序類型，然后生成合適的表現代碼。一般地，Web頁面中的輸入框使用客戶端JavaScript進行輸入合法性驗證，但如果瀏覽器不支持JavaScript或者禁用了JavaScript，用戶輸入驗證就會轉到服務器端。