.NET Framework環境下的ASP網頁製作

網路公司裁員、網站關閉、電子報停刊…，經歷電子商務的退潮之後，有人開始質疑電子商務是不是被高估了。也許網際網路不再編織賺大錢的美夢，但經過這幾年的洗禮，網際網路已經成為大眾生活中的一部份，據說台北市的國中生能製作網頁者已經相當普遍，由此可見一斑，當網頁製作變成一般知識之後，想生存於網際網路，夠不夠專業將是決勝因素。

在 .NET Framework底下，筆者很欣慰ASP(Active Server Pages)變得更專業了，簡單地回顧過去的ASP，我們至少可以指出幾個缺點：

只能使用VB Script或Java Script這兩種程式語言來開發ASP。

沒有好的偵錯程式(Debugger)。

網頁結構會隨著程式變大而一團亂。

ADO無法直接與DataGrid元件結合。

本期筆者將為您解說ASP的新面貌(微軟把這個新的ASP稱為ASP.NET)。

從ASP到ASP.NET

ASP會變得很紅，恐怕連微軟也覺得意外，因為ASP一直都附屬於IIS，算不上獨立的產品。IIS版本與ASP版本的對應如下：

IIS 版本

附帶在 IIS 底下的 ASP 版本

IIS 3.0

ASP 1.0

IIS 4.0

ASP 2.0

IIS 5.0

ASP 3.0

有人會用1.0、2.0、3.0來區分ASP的版本，但筆者不以為然，因為從ASP 1.0版到3.0版，微軟並沒有花太多心思來改良ASP，只是因為IIS改版了，所以ASP也跟著做微幅的改版，因此從ASP 1.0版到3.0版，在功能上並沒有顯著的改變，所以不管ASP 1.0、2.0或3.0，筆者都叫它們ASP。

隨著ASP的使用者越來越多，希望ASP更好的聲音也越來越強烈，也許是從善如流，也許是為了推廣 .NET Framework，微軟針對ASP的使用者做了市場調查，找出ASP必須改良的地方，而發展了下一代的ASP，也就是ASP.NET(或者稱為ASP+)。

ASP.NET與ASP的相容性

從ASP升級到ASP.NET，大家最擔心的問題可能是「會不會影響既有ASP網頁的運作」，筆者將ASP作業平台升級到ASP.NET作業平台之後(本文撰寫時所安裝的ASP.NET版本是Beta 1)，還沒有發現既有的ASP網頁不能運作或必須修改的。

在實際運作上，當ASP網頁(以 .asp為副檔名)被瀏覽時，IIS會啟動asp.dll來執行ASP網頁，而當ASP.NET網頁(以 .aspx為副檔名)被瀏覽時，IIS則會啟動xspwp.exe來執行ASP.NET網頁，兩者的執行檔案不同，因此不只是安裝ASP.NET之後，不會影響既有ASP網頁的運作，實際上ASP網頁及ASP.NET網頁是並存的。

另一個常問的問題是：需要將現有的ASP網頁轉換成ASP.NET網頁嗎？由於ASP網頁及ASP.NET網頁是並存的，因此運作得很順利的ASP網頁可以暫時不必修改，至於哪些網頁必須採用ASP.NET？以下是筆者的建議：

希望效能更高時：當ASP.NET網頁第一次被瀏覽時，Server會先將其編譯成MSIL(Microsoft Intermediate Language)，並且儲存下來，而再度被瀏覽時，即不再重新編譯(除非 .aspx檔案的內容有所改變)，因此可以提升不少效能。此外，ASP.NET還具備網頁及資料Cache功能(見稍後介紹)，亦可提昇網頁的回應速度。

需要經常維護或修改的網頁：由於ASP.NET採用VB7為程式語言，具備完整的物件導向功能，有助於網頁的維護。

未來新開發的網頁：既然ASP.NET功能優於ASP，未來開發的網頁當然要採用ASP.NET。

程式語言的改變

從ASP到ASP.NET，其中的改變相當多，不過與ASP網頁製作者最有切身關係的應該是程式語言的改變，ASP只接受VB Script及Java Script兩種程式語言，但是對ASP.NET來說，舉凡可以編譯成MSIL的程式語言，都是ASP.NET可以接受的程式語言。

筆者在Run!PC前3期的「.NET Framework -- 微軟新一代的軟體開發環境」一文中介紹過MSIL，它是一種中介語言，介於高階程式語言(例如VB)及機器碼之間的語言，在ASP.NET底下，我們撰寫的程式語言也會先編譯成MSIL，然後MSIL再被編譯成機器碼加以執行，過程如圖-1，ASP.NET也是採用此一模式，除了會輸出資料到瀏覽器之外，ASP.NET網頁與其他的程式語言的工作模式都是相同的。

圖-1 ASP.NET 網頁編譯執行的過程

執行效能的質疑

第一次接觸ASP.NET網頁的人可能會有這樣的疑問：「執行效能好像不如ASP網頁？」，關於這個問題，讓筆者從運作模式來談起，首先請看圖-2，可看出ASP.NET網頁比ASP網頁要多一次的編譯工作。

圖-2 ASP與ASP.NET運作模式的比較

儘管ASP.NET比ASP網頁多一次的編譯工作，但這並不表示ASP.NET的執行效能一定比較差，參考圖-2，ASP.NET階段二的編譯執行速度優於ASP，但ASP.NET階段一的編譯速度卻慢於ASP，簡單地說，ASP.NET階段一及階段二合起來的時間＞ASP執行的時間。

如果從以上的比較來看，ASP.NET確實比ASP慢，但是請再把網頁的瀏覽分成以下兩種情況：(1) 網頁第一次被瀏覽 (2) 網頁第二次被瀏覽，如圖-3，ASP.NET 網頁第一次被瀏覽時，會經過兩階段的編譯，所以速度較慢，但第一次被瀏覽之後，MSIL會被儲存下來，所以當同一網頁第二次被瀏覽時，只須花費從MSIL編譯成機器碼然後執行的時間，結果比ASP網頁來的快，整體的比較如下：(＞表示較快)

ASP.NET 網頁第二次被瀏覽＞ ASP網頁＞ ASP.NET 網頁第一次被瀏覽

圖-3 第一次瀏覽及第二次瀏覽的差異

.NET Framework 物件類別的使用

微軟宣稱 .NET Framework有許多好處，但筆者最看重的是 .NET Framework所提供的物件類別，.NET Framework所提供的物件類別多達數百種，包含資料結構、資料庫、繪圖、網路、XML、執行緒、目錄服務、安全性…等，應有盡有。

以往ASP網頁雖然可以使用ActiveX物件，但其實只限定於ActiveX物件中的ActiveX DLL，不像一般應用程式(例如VB程式、C++程式)可以同時使用ActiveX DLL、ActiveX EXE及ActiveX Component等多種ActiveX物件，不過這個現象在 .NET Framework底下已經有所改善，在 .NET Framework所提供的物件類別中，除了少數與螢幕輸出有關的物件類別(例如WinForm及Console)是ASP.NET網頁所不可使用之外，其他物件類別則都是ASP.NET網頁可以使用的。

註：WinForm包含windows(視窗)相關的物件類別、Console則是DOS文字輸出模式的物件類別，對ASP.NET來說，其輸出之標的為瀏覽器，所以不可以輸出資料到Windows視窗及DOS文字視窗，ASP.NET專用的輸出物件類別稱為WebForm，則是Windows應用程式不可使用的。

WebForm與Server控制元件

在ASP的網頁製作中，如果我們想設計一個輸入表單(Form)，大概只能使用HTML輸入欄位(或稱為控制元件)，ASP.NET在這方面做了很大的加強，在其WebForm裡面，我們可以佈置各種控制元件(統稱Server控制元件)，這些控制元件包含：

Server控制元件

功能

CheckBox、CheckBoxList

加強HTML核取方塊的功能

RadioButton、 RadioButtonList

加強HTML選擇鈕的功能

TextBox

加強HTML文字輸入方塊的功能

ListBox 、DropDownList

加強HTML下拉式選單的功能

Table、TableRow、TableCell

加強HTML表格的功能

Label

加強HTML文字的功能

Image、 ImageButton

加強HTML圖片的功能

LinkButton、 HyperLink

加強HTML連結的功能

Panel

可將控制元件分成多個區塊

AdRotator

廣告迴旋板

Calendar

日期的顯示及選擇

資料驗證類控制元件

可在不必撰寫程式的情況，幫我們驗證使用者所輸入的資料是否正確

DataGrid、DataList、Repeater

資料庫的顯示

除了提供更豐富的控制元件之外，WebForm的另一個優點是可以記錄網頁的狀態，以往在ASP網頁中，若要記錄Client端的狀態，必須使用Session或Cookie物件，但不管是Session或Cookie物件，都必須在上網者開啟瀏覽器的Cookie功能之下方可運作，ASP.NET改善了此一現象，只要我們將Server控制元件佈置在WebForm之中，WebForm就會記錄所有Server控制元件的狀態(例如控制元件中所輸入的文字)。

記錄控制元件狀態的能力，以須分成多次輸入的表單最為方便，以圖-4的輸入表單為例，若使用ASP的設計，在步驟一及步驟二所輸入的資料必須記錄在Session或Cookie物件中，供步驟三讀取，但是對ASP.NET網頁，只要將步驟一、步驟二、步驟三的Server控制元件佈置在同一個WebForm之中，則不管網頁執行到哪一個步驟，都可以讀取上網者在Server控制元件中所輸入的資料。

圖-4 分成多次輸入的表單

ADO+與資料控制元件

.NET Framework所提供的資料庫存取物件稱為ADO+(Active Data Object+)，雖然有不少觀念與ADO相類似，但卻是全新的物件，為什麼已經有ADO了，還要再提供ADO+呢？筆者覺得原因可能有幾：

採用XML做為資料交換格式：由於XML已經成為網際網路交換資料的標準，這是個不得不的舉動。

延伸資料的範圍：在ADO底下，任何資料都必須透過OLD DB或ODBC來存取，ADO+ 並無此一限制，任何程式都可以藉助ADO+ 所提供的物件讓自己成為新資料格式的提供者，這因此延伸了可存取之資料的範圍。

與資料控制元件的整合：以往我們撰寫ASP網頁時，最不方便的地方是資料庫內容的顯示，為了顯示資料庫的內容，大概必須藉助ADO的Recordset物件逐筆讀取資料錄，然後再逐筆將其顯示出來，程式較冗長，在ASP.NET網頁中，我們只要佈置好DataGrid、DataList或Repeater這一類資料控制元件，然後與ADO+ 進行繫結，DataGrid等控制元件就會自動顯示資料庫的內容。參閱圖-5及圖-6就是分別使用DataGrid及DataList控制元件顯示資料庫內容的網頁。

圖-5 http://www.kjedu.com.tw/kjaspx/ch01/AspxPage.aspx 網頁

圖-6 http://www.kjedu.com.tw/kjaspx/ch01/DataList.aspx

Cache與效能的提升

為了提升執行效能，ASP.NET網頁會先被編譯成MSIL儲存在硬碟中，而下次當該網頁再度被瀏覽時，就可以直接執行被儲存下來的MSIL(細節請參閱「執行效能的質疑」段落的說明)，除了此一強化執行效能的動作之外，ASP.NET所提供的Cache(快取記憶體)功能亦可提升執行效能。ASP.NET提供的Cache功能分成Output Cache及Data Cache兩種。

Output Cache與網頁快取

圖-7 Output Cache與網頁快取

參閱圖-7，所謂Output Cache，是在執行MSIL之後，先將結果寫入Output Cache，然後再將Output Cache下傳到瀏覽器，而將來如果瀏覽同一網頁，ASP.NET會先判斷該網頁是否有Output Cache存在，如果有，則直接將Output Cache下傳到瀏覽器，不會經過編譯 .aspx及執行MSIL的過程，故能提升執行效能。

要啟用Output Cache的方法十分簡單，只要在 .aspx網頁的最前面加上以下標示即可：

<%@ OutputCache Duration="秒數" %>

其中Duration表示Output Cache保留在系統中的秒數，例如：

<%@ OutputCache Duration="10" %>

結果網頁的Output Cache將會保留在系統中10秒鐘，而凡是在這10秒內瀏覽此一網頁，ASP.NET就會直接將Output Cache下傳給瀏覽器，省略了編譯的動作。

Data Cache與資料快取

除了將整個網頁儲存於Output Cache之外，我們也可以將局部資料儲存於Data Cache(以下簡稱Cache)。Cache的用法與Application物件很類似，例如：

' 將資料或物件存放在Application物件中

Application("key1") = "這是字串"

Application("key2") = obj

' 將資料或物件存放在Data Cache中

Cache("key1") = "這是字串"

Cache("key2") = obj

不過筆者必須說明的是Data Cache所佔用的記憶體隨時可能會被釋放(視系統記憶體當時使用的情況)，所以每當我們要讀取Data Cache時，要先判斷Cache("key") 是否等於Nothing，若不等於Nothing，表示Cache("key") 還存在於系統中，方可讀取。

提供偵錯工具

在撰寫程式的過程中，難免會有錯誤產生，如何除錯對任何一個程式設計師來說，都是很重要而且是無可避免的工作。ASP的偵錯工具十分欠缺，為了改善此一缺失，ASP.NET提供以下幾種偵錯方法：

設定config.web的customerrors節區

使用追蹤(Trace)功能

偵錯工具程式(Debugger)

設定config.web的customerrors節區

當網頁產生錯誤而無法進一步編譯或執行時，ASP.NET會顯示如圖-8之畫面，此一畫面只告訴我們程式有錯，至於哪一行程式錯誤，則未顯示。為了讓ASP.NET顯示進一步的錯誤訊息，可在config.web檔案中增加customerrors節區的設定，如下：

</configuration>

結果瀏覽之後可看到更詳細的錯誤指示畫面(如圖-9)

圖-8 ASP.NET網頁編譯或執行錯誤的畫面 (圖略)

圖-9 ASP.NET網頁編譯或執行錯誤的畫面(錯誤訊息較詳細)(圖略)

使用Trace追蹤功能

所謂Trace功能是在網頁的最前面加上以下標示：

<%@ Page Trace="True" %>

結果網頁被瀏覽之後，將會額外顯示一些資訊，如圖-10，而這些資訊有助於我們研判程式的狀況，做為偵錯時的參考。

圖-10 Trace功能啟用之後的網頁(圖略)

在圖-10畫面中，除了網頁正常顯示的內容之外，額外顯示的資訊可分成以下區段：

Request Details：透過Request方式向瀏覽器所讀取之資料。

Trace Information：事件發生或程式執行的過程。

Control Tree：網頁所使用之控制元件及控制元件之間的階層關係。

Cookies Collection：網頁所使用的Cookie。

Headers Collection：瀏覽器的表頭資訊。

Server Variables：Server變數，也就是我們可以透過Request. ServerVariables() 所讀取的資訊。

除了讓ASP.NET自動顯示以上訊息之外，我們也可以將程式執行過程中的資料顯示在Trace Information區段中，方法是呼叫Trace.Write或Trace.Warn，例如：

Trace.Write("UploadFile()", "進入UploadFile事件程序")

Trace.Warn ("UploadFile()", "進入For迴圈")

結果可將訊息輸出到Trace Information區段，供我們做為偵測程式的參考。

偵錯工具程式(Debugger)

ASP.NET提供的Debugger程式很像VB的操作介面，可以讓我們設定中斷點、逐步執行程式、觀察變數及堆疊的情況…等，是偵錯的利器。使用Debugger之前，須在config.web檔案中增加以下的設定：

接下來啟動C:\Program Files\Microsoft.Net\FrameworkSDK\GuiDebug目錄的DbgUrt.exe，然後利用以下步驟即可偵測 .aspx網頁：

1. 選取DbgUrt.exe功能表的「Debug -> Processes」，待出現「Processes」交談窗時，核取「Show system processes」及「Show processes in all sessions」，然後在「Available processes」欄位的最下面找到xspwp.exe(註：如果沒有看到xspwp.exe，請先啟動瀏覽器瀏覽任意 .aspx網頁，然後再按下「Refresh」鈕)，選取之後，再按下「Attach」鈕，過程如圖-11。

圖-11 DbgUrt.exe的「Process」交談窗(圖略)

2. 接下來會出現「Attach to process」交談窗(如圖-12)，請按下「OK」鈕。

圖-12 Attach to process 交談窗(圖略)

3. 接下來回到步驟1的「Processes」交談窗，請按下「Close」鈕。

4. 選取DbgUrt.exe功能表的「File -> Open -> File」選取您想偵測的 .aspx檔案，在此您可以選取多個想要偵測的檔案。

物件的開發

由於ASP.NET以VB7為程式語言，所以VB7所有物件導向的功能也都能夠發揮在ASP.NET網頁製作中，而除了程式語言所提供物件導向功能之外，ASP.NET可以開發一種網頁專用的物件 -- pagelet(網頁小配件)。

何謂Pagelet(網頁配件)？以生活中的實例來看，當我們裝飾耶誕樹時，往往會買些小配件，然後將它們佈置在喜歡的位置，Pagelet的觀念也是相類似的，某些常用的配件，我們可以將它們設計Pagelet，讓其他網頁來使用，舉個更實際的例子，例如我們網頁中佈置一個Label控制元件及一個TextBox控制元件，其作用就是在網頁中插入了一個Label類型的Pagelet及一個TextBox類型的Pagelet。

本文讓筆者先展示一個簡單的Pagelet，此一Pagelet命名為Footer.ascx，如下：(註：Pagelet須以 .ascx 為副檔名)

<Hr>

學 Visual Basic 找王國榮</A>

</Div>

檢視Footer.ascx的內容，您會發現其中只有HTML標示，完全沒有ASP.NET的程式，這樣的 .ascx檔案也能構成Pagelet嗎？答案是肯定的，最簡單的Pagelet就是只含有HTML標示的 .ascx檔案，接著讓我們來看看使用這個這個Pagelet的網頁UseFoot.aspx：

<%@ Register TagPrefix="kj" TagName="Footer" Src="Footer.ascx" %>

<Html>

<H3>使用最簡單的 Pagelet -- UseFoot.aspx<HR></H3>

檢視 Footer.ascx 的內容，您會發現其中只有 HTML 標示，完全沒有

ASP+ 的程式，這樣的 .ascx 檔案也能構成 Pagelet 嗎？答案是肯定

的，最簡單的 Pagelet 就是只含有 HTML 標示的 .ascx 檔案。

</Blockquote>

<kj:Footer id="Footer1" runat="server"/>

</Body>

</Html>

網頁瀏覽的結果如圖-13。

圖-13 UseFoot.aspx瀏覽的結果

除了只含有HTML標示最簡單的Pagelet之外，Pagelet也可以含有屬性及方法，對於含有屬性及方法的Pagelet來說，其用法與Server控制元件完全相同。當我們覺得 .NET Framework 所提供的Server控制元件不夠用時，可以利用製作Pagelet的功能來建立我們自己的Server控制元件。

Web Services

不像ASP網頁只能存取本機資料庫，ASP.NET則提供了Web Services功能讓我們跨越網際網路存取遠端的資源。在VB6時代，微軟發表了RDS(Remote Data Service)，也可以讓我們存取網際網路上另一部Server的資料庫，但它仍有兩大缺點：(1) 一般使用者上手不易 (2) 無法跨越平台：使用RDS跨越網際網路存取資料庫，不管Server端或Client端，都必須使用Windows作業系統。

Web Services(Web服務)改良了RDS的缺點，除了變得比較容易上手之外，Web Services採用XML為資料傳輸的格式，使得資料得以跨越平台，而更重要的是，ASP.NET網頁也可以享用這種服務，也可以提供這種服務。

在作業模式上，讓筆者舉個實例來說明，請參閱圖-14，假設瀏覽器會存取Server A的網頁，但Server A的資料庫來自ServerX，那麼Server X要提供一存取資料庫之Web Service，另一方面Server A則要建立Web資料庫代理程式，然後透過Web資料庫代理程式與Web Service的資料交換(採用XML格式)，進而達到存取Server X資料庫的目的。

圖-14 存取Web資料庫(跨越網際網路的資料庫)

結語

也許過去兩三年電子商務真的被高估了，但網頁製作技術卻已成為資訊人必備的知識。雖然自從微軟發表IIS以來，ASP一直被低估了，所以只是IIS的附屬品，現在很高興ASP.NET終於從IIS之中獨立出來，而且功能與VB、C#…等程式語言看齊，相信未來的ASP網頁製作將進入另一個嶄新的世紀。