.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 ？以下是筆者的建議： > > 1. 希望效能更高時：當 ASP.NET 網頁第一次被瀏覽時， Server 會先將其編譯成 MSIL(Microsoft Intermediate Language) ，並且儲存下來，而再度被瀏覽時，即不再重新編譯 ( 除非 .aspx 檔案的內容有所改變 ) ，因此可以提升不少效能。此外， ASP.NET 還具備網頁及資料 Cache 功能 ( 見稍後介紹 ) ，亦可提昇網頁的回應速度。 > 2. 需要經常維護或修改的網頁：由於 ASP.NET 採用 VB7 為程式語言，具備完整的物件導向功能，有助於網頁的維護。 > 3. 未來新開發的網頁：既然 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="秒數"

1&gt; 
2&gt; 其中  Duration  表示  Output Cache  保留在系統中的秒數，例如： 
3&gt;
4&gt;&gt; ```
5@ 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 節區的設定，如下： > >>

1<configuration>   
2&gt;  ** <customerrors mode="off"></customerrors> **   
3&gt;  </configuration>

> > 結果瀏覽之後可看到更詳細的錯誤指示畫面 ( 如圖 -9) > > 圖-8 ASP.NET網頁編譯或執行錯誤的畫面 (圖略) > > 圖-9 ASP.NET網頁編譯或執行錯誤的畫面(錯誤訊息較詳細)(圖略)

使用Trace追蹤功能

> 所謂 Trace 功能是在網頁的最前面加上以下標示： > >> ``` @ Page Trace="True"

 1&gt; 
 2&gt; 結果網頁被瀏覽之後，將會額外顯示一些資訊，如圖  -10  ，而這些資訊有助於我們研判程式的狀況，做為偵錯時的參考。 
 3&gt; 
 4&gt; _圖-10 Trace功能啟用之後的網頁(圖略)_
 5&gt; 
 6&gt; 在圖  -10  畫面中，除了網頁正常顯示的內容之外，額外顯示的資訊可分成以下區段： 
 7&gt; 
 8&gt;   * Request Details：透過  Request  方式向瀏覽器所讀取之資料。 
 9&gt;   * Trace Information：事件發生或程式執行的過程。 
10&gt;   * Control Tree：網頁所使用之控制元件及控制元件之間的階層關係。 
11&gt;   * Cookies Collection：網頁所使用的  Cookie  。 
12&gt;   * Headers Collection：瀏覽器的表頭資訊。 
13&gt;   * Server Variables：  Server  變數，也就是我們可以透過  Request. ServerVariables()  所讀取的資訊。 
14&gt; 
15
16&gt; 
17&gt; 除了讓  ASP.NET  自動顯示以上訊息之外，我們也可以將程式執行過程中的資料顯示在  Trace Information  區段中，方法是呼叫  Trace.Write  或  Trace.Warn  ，例如： 
18&gt;
19&gt;&gt; Trace.Write("UploadFile()", "進入UploadFile事件程序")   
20&gt;  Trace.Warn ("UploadFile()", "進入For迴圈") 
21&gt; 
22&gt; 結果可將訊息輸出到  Trace Information  區段，供我們做為偵測程式的參考。 
23
24###  _偵錯工具程式(Debugger)_
25
26&gt; ASP.NET  提供的  Debugger  程式很像  VB  的操作介面，可以讓我們設定中斷點、逐步執行程式、觀察變數及堆疊的情況…等，是偵錯的利器。使用  Debugger  之前，須在  config.web  檔案中增加以下的設定： 
27&gt;
28&gt;&gt;

 1&gt; 
 2&gt; 接下來啟動  C:\Program Files\Microsoft.Net\FrameworkSDK\GuiDebug  目錄的  DbgUrt.exe  ，然後利用以下步驟即可偵測  .aspx  網頁： 
 3&gt; 
 4&gt; **1** .  選取  DbgUrt.exe  功能表的「  Debug -&gt; Processes  」，待出現「  Processes  」交談窗時，核取「  Show system processes  」及「  Show processes in all sessions  」，然後在「  Available processes  」欄位的最下面找到  xspwp.exe(  註：如果沒有看到  xspwp.exe  ，請先啟動瀏覽器瀏覽任意  .aspx  網頁，然後再按下「  Refresh  」鈕  )  ，選取之後，再按下「  Attach  」鈕，過程如圖  -11  。 
 5&gt; 
 6&gt; _圖-11 DbgUrt.exe的「Process」交談窗(圖略)_
 7&gt; 
 8&gt; **2** .  接下來會出現「  Attach to process  」交談窗  (  如圖  -12)  ，請按下「  OK  」鈕。 
 9&gt; 
10&gt; _圖-12 Attach to process 交談窗(圖略)_
11&gt; 
12&gt; **3** .  接下來回到步驟  1  的「  Processes  」交談窗，請按下「  Close  」鈕。 
13&gt; 
14&gt; **4** .  選取  DbgUrt.exe  功能表的「  File -&gt; Open -&gt; File  」選取您想偵測的  .aspx  檔案，在此您可以選取多個想要偵測的檔案。 
15
16##  物件的開發 
17
18&gt; 由於  ASP.NET  以  VB7  為程式語言，所以  VB7  所有物件導向的功能也都能夠發揮在  ASP.NET  網頁製作中，而除了程式語言所提供物件導向功能之外，  ASP.NET  可以開發一種網頁專用的物件  \-- pagelet(  網頁小配件  )  。 
19&gt; 
20&gt; 何謂  Pagelet(  網頁配件  )  ？以生活中的實例來看，當我們裝飾耶誕樹時，往往會買些小配件，然後將它們佈置在喜歡的位置，  Pagelet  的觀念也是相類似的，某些常用的配件，我們可以將它們設計  Pagelet  ，讓其他網頁來使用，舉個更實際的例子，例如我們網頁中佈置一個  Label  控制元件及一個  TextBox  控制元件，其作用就是在網頁中插入了一個  Label  類型的  Pagelet  及一個  TextBox  類型的  Pagelet  。 
21&gt; 
22&gt; 本文讓筆者先展示一個簡單的  Pagelet  ，此一  Pagelet  命名為  Footer.ascx  ，如下：  (  註：  Pagelet  須以  .ascx  為副檔名  ) 
23&gt;
24&gt;&gt;

> > 學 Visual Basic 找王國榮 >

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

使用最簡單的 Pagelet -- UseFoot.aspx

> 檢視 Footer.ascx 的內容，您會發現其中只有 HTML 標示，完全沒有 > ASP+ 的程式，這樣的 .ascx 檔案也能構成 Pagelet 嗎？答案是肯定 > 的，最簡單的 Pagelet 就是只含有 HTML 標示的 .ascx 檔案。 >

> ** > **>``` > > 網頁瀏覽的結果如圖 -13 。 > > _![](http://www.kj.com.tw/2001/mag/Image130.gif) > 圖-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 網頁製作將進入另一個嶄新的世紀。